<commit_before># linux_kernel_cves
This is a simple project to track CVEs in the upstream linux kernel. 
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 separate files for each LTS 
stream. These files list all CVEs that possibly affect that stream and 
when/if they were fixed.

### 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 (Currently limited to after 2004, see 
  [#3](../../issues/3).
  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 <commit_msg>Fix link in README.md<commit_after># linux_kernel_cves
This is a simple project to track CVEs in the upstream linux kernel. 
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 separate files for each LTS 
stream. These files list all CVEs that possibly affect that stream and 
when/if they were fixed.

### 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 (Currently limited to after 2004, see 
  [#3](../../issues/3)).
  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 
{'fraction_non_alphanumeric': 0.04250495891187305, 'fraction_numerical': 0.0056673278549164065, 'mean_word_length': 3.6508563899868247, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '994510', 'n_tokens_mistral': 936, 'n_tokens_neox': 887, 'n_words': 589}