Linux Kernel official feed

[adulau]

https://git.kernel.org/pub/scm/linux/security/vulns.git/

[Rafiot]

This repository is not clear on what it contains.

• gsd seems to contain a subset of reports
• cve seems to contain the CVE entry and a .mbox file that is a mail with human readable notes regarding the vulnerability. => might make sense to import that as an extra context for the CVE?

We absolutely do not want to load the repository recursively as it contains the cvelistv5 repo too.

[adulau]

Yep it's not very clear. We can keep the issue and close it for historical purpose.

[jbmaillet]

FWIW, maybe playing Captain Obvious:

For some historical reasons, kernel OSV Id are "GSD", just like GitHub Id are "GHSA" for GitHub Security Advisory). GSD stands for "Global Security Database", formely UVI. Search "GSD" in OpenSSF Open Source Vulnerability schema, https://ossf.github.io/osv-schema/, this will lead to https://github.com/cloudsecurityalliance/gsd-database. See also https://github.com/ossf/osv-schema. UVI was for "Universal Vulnerability Identifier".

These kernel GSD from the kernel sub-ecosystem of OSV can be seen here:
https://osv.dev/list?ecosystem=Linux

As for what could be an "official" kernel CVE feed, for practical human readable purposes I monitor:
https://lore.kernel.org/linux-cve-announce/

In my understanding the git repo you point at:
https://git.kernel.org/pub/scm/linux/security/vulns.git/
...would be the tooling + raw data Greg KH uses.

This podcast with GreKH has some interesting details about the why and how, and this script tooling:
https://opensourcesecurity.io/2024/02/25/episode-417-linux-kernel-security-with-greg-k-h/

[Rafiot]

The main question for this project is if there are more contextual information to attach automatically to a kernel vuln when someone search for it on vulnerability lookup. And I'm not sure it is the case.

[jbmaillet]

I think it is for https://lore.kernel.org/linux-cve-announce/

Example with: https://nvd.nist.gov/vuln/detail/CVE-2024-27437

Not much info / metadata, as usual. But on linux-cve-announce:
https://lore.kernel.org/linux-cve-announce/2024040551-CVE-2024-27437-cc07@gregkh/
...with have the version and sha1 when the bug was introduced (the NVD provide at best a version) and the sha1 the issue was fixed on all living branches (the NVD never provide the sha1, and rarely list all branches).

We also have a list of the source code files impacted, here only 1, drivers/vfio/pci/vfio_pci_intrs.c.

All this is machine readable (but there's better, see below). Working on embedded devices I have to deal with 800+ CVE per kernels, each kernel build from sources, with one or more custom configuration, these information's are extremely valuable to filter the 95% of false positives I get from the NVD.

The kernel did a fantastic job as a CNA. Better yet, as of today CVE.org already support these metadata send by Greg KH and his colleagues:
https://www.cve.org/CVERecord?id=CVE-2024-27437
...clicking on the "view JSON" in the upper right corner, we can see all this available in CVE.org JSON record:
https://cveawg.mitre.org/api/cve/CVE-2024-27437

...but they are lost in the transfer to the NVD (not mentioning current NVD problems...)

[Rafiot]

Alright, I'm reopening this one and will figure out how I can get the email content as a contextual information for the CVE

[adulau]

So the valuable source it's then in https://git.kernel.org/pub/scm/linux/security/vulns.git/tree/cve/published which also content the message-id reference along with the CVE and the raw data of the mbox file. So then it makes sense to have it in vulnerability-lookup.

[jbmaillet]

(Note that as for me, I don't use cve-search. I used it between 2016 and 2019, and then switched to another system. I'm just here as part as my regular technology watch.)

[adulau]

@jbmaillet In any case, thanks for the feedback.