One thing I've noticed is that sometimes a vulnerability patch involves making changes to code involving memory management. For example, in tmux, CVE-2020-27347, commit a868bacb46e3c900530bed47a1c6f85b0fbe701c:
diff --git a/input.c b/input.c
index 42a60c92..c280c0d9 100644
--- a/input.c
+++ b/input.c
@@ -1976,8 +1976,13 @@ input_csi_dispatch_sgr_colon(struct input_ctx *ictx, u_int i)
free(copy);
return;
}
- } else
+ } else {
n++;
+ if (n == nitems(p)) {
+ free(copy);
+ return;
+ }
+ }
log_debug("%s: %u = %d", __func__, n - 1, p[n - 1]);
Note that free(..) is called here, so it involved memory management. Now this CVE was mapped to CWE-121 Stack-based Buffer Overflow, so it doesn't help us here - but it might be a useful thing to look at patches and do a basic text string search for things like malloc( and free(
It'll be useful especially if we don't have CWE mapping, or might be useful some other way. Maybe casting for overflow? Anyway - interesting observation for an easy metric to collect.
One thing I've noticed is that sometimes a vulnerability patch involves making changes to code involving memory management. For example, in tmux, CVE-2020-27347, commit
a868bacb46e3c900530bed47a1c6f85b0fbe701c:Note that
free(..)is called here, so it involved memory management. Now this CVE was mapped to CWE-121 Stack-based Buffer Overflow, so it doesn't help us here - but it might be a useful thing to look at patches and do a basic text string search for things likemalloc(andfree(It'll be useful especially if we don't have CWE mapping, or might be useful some other way. Maybe casting for overflow? Anyway - interesting observation for an easy metric to collect.