“A quick search of the CVE database turns up 80 CVE numbers
related to kernel vulnerabilities so far this year. At one recent
conference or another, while talking with a prominent kernel
developer, your editor confessed that he found that number to be
discouragingly high. In an era where there is clearly an increasing
level of commercial, criminal, and governmental interest in
exploiting security holes, it would be hard to be doing enough to
avoid the creation of vulnerabilities. But, your editor wondered,
could we be doing more than we are? The response your editor got
was, in essence, that the bulk of the holes being disclosed were
ancient vulnerabilities which were being discovered by new static
analysis tools. In other words, we are fixing security problems
faster than we are creating them.“That sort of claim requires verification; it is also amenable
to being verified by a researcher with sufficient determination and
pain resistance. Your editor decided to give it a try. “All” that
would be required, after all, was to look at each vulnerability and
figure out when it was introduced. How hard could that be?“So, the basic process followed was this: pick a CVE entry, find
the patch which closed the hole, then dig through the repository
history and other resources in an attempt to figure out just when
the problem was first introduced into the kernel. In some cases,
the answer was relatively easy to find; others were sufficiently
hard that your editor eventually gave up.”