linux_kernel_cves: Tracking CVEs for the linux Kernel
linux_kernel_cves
This is a simple project to track CVEs in the upstream Linux kernel. Individual distro’s (RHEL, Debian, Ubuntu, etc) often do a good job of tracking CVEs for their own kernels but this information is lacking for the upstream kernel. This project aims to help out with this void. Currently, all output for this is stored in the CVEs.txt file. The output was generated automatically through a set of tools that have not been fully tested or made public yet.
How to see the data
There are two ways to view/consume the data. The easiest is the web front end at www.linuxkernelcves.com. Here can you can view CVEs by a stream or by CVE id. The second way is on the GitHub page here. On the GitHub, the data is laid out in both JSON and text format. Both pages offer the same data.
Linux Security Note
Tracking, mitigating, and patching CVEs is just a small part of maintaining a secure kernel. Let me be clear, you can patch all known CVEs and still be vulnerable. Some risk can be mitigated through properly configuring your kernel/system. I suggest you visit the Kernel Self Protection Project and other kernel security pages for more information.
Reading stream reports
Below is a list of definitions for certain strings you might see in a stream report. The only CVEs that should appear in the stream document are ones that potentially affect that stream. (ie. ones that were not fixed prior to the first release version and were not introduced after the release version) If no fixing commit is known for a CVE, then by default it is assumed to present in all streams after it was introduced.
- ‘Fix unknown’: No fixing commit in the commit maps or the commit is invalid
- ‘Fixed with X’: Fixing commit was seen in the stream and first appears in version X
- ‘Fix not seen in stream’: The fixing commit is known and valid, but not seen in this stream (ie. stream is still vulnerable)
Overview of Process
The process for generating these documents is focused on being as automated as possible. Below is the general outline of steps.
- Take a list of all kernel CVEs (Currently limited to after 2004, see #3).
- If the issue is marked as Vendor-specific, ignore it.
- Get the Breaking/Fixing Commits. This is retrieved from the internal cache first, if not present it pulls from Ubuntu, Debian, etc to try and fill that information in.
- Using those commit ids, get the first tags in the mainline that they appear.
- Using that version timeline, for each stream that would be vulnerable perform steps 6 through 8.
- Find the commit who has the commit message that matches the commit message from the mainline. This is the fixing commit in that stream.
- Record the commit id and get the earliest tag in the stream which has that commit.
- Output information to stream document.
- Update JSONs.
Copyright (c) 2017 Nicholas Luedtke
