README.md - mirrors/github.com/nluedtke/linux_kernel_cves - Git at Google

 # 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
	# 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