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. The output was generated automatically through a set of tools that has 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 stream or by CVE id. The second way is this github page. Here, the data is laid out in both JSON and text format.

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.

1. Take list of all kernel CVEs
2. If the issue is marked as Vendor specific, ignore it.
3. 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.
4. Using those commit ids, get the first tags in the mainline that they appear.
5. Using that version timeline, for each stream that would be vulnerable perform steps 6 through 8.
6. Find the commit who has the commit message that matches the commit message from the mainline. This is the fixing commit in that stream.
7. Record the commit id and get the earliest tag in the stream which has that commit.
8. Output information to stream document.
9. Update JSONs.

Accuracy

The bulk of the data is autogenerated or pulled from other open sources. While every effort is taken to ensure its accuracy, no promise of absolute accuracy can be made. If you think a CVE is missing or is not completely accurate, please fill out an issue to have the data looked at and changed. 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.

Development

Want to contribute? Great!

Data Contributions

Any additions/removals/updates to the data should start with an Issue. Please be as accurate and complete as possible when requesting a change so the information can be validated as quickly as possible.

Code Contributions

All code changes or enchancements must be done through a Pull Request to the staging branch. No PRs directly to master will be accepted.

Known Issues

• Multiple commits to fix a CVE not handled