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 has not been fully tested or made public yet.
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 stream or by CVE id. The second way is on the github page at https://github.com/nluedtke/linux_kernel_cves/. On the github, the data is laid out in both JSON and text format. Both pages offer the same data.
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.
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)
The process for generating these documents is focused on being as automated as possible. Below is the general outline of steps.
- Take 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.
This is currently autogenerated and will go through testing before any promises of accuracy are made. The eventual goal would be to have a community curated list of CVEs along with when the code was introduced and when it was fixed.
Want to contribute? Great! Due to the vary early stages of this work the best places is through github issues to start discussions and requests. Updating the commit maps with the breaks/fixes information is also very helpful. File a merge request and it will accepted when the information is validated. If/When this idea matures, direct contributions will of course be accepted.
- Breaks/Fixes lists accuracy not 100% (This is slowly being corrected)
- Multiple commits to fix a CVE not handled