Ecosyste.ms: Awesome

An open API service indexing awesome lists of open source software.

Awesome Lists | Featured Topics | Projects

https://github.com/nluedtke/linux_kernel_cves

Tracking CVEs for the linux Kernel
https://github.com/nluedtke/linux_kernel_cves

cve linux linux-kernel linux-security security-audit security-vulnerability tracker tracking-cves

Last synced: about 1 month ago
JSON representation

Tracking CVEs for the linux Kernel

Awesome Lists containing this project

README 

        
# 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][2]. 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][1] 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



[1]: https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project

[2]: https://www.linuxkernelcves.com