enhancement: new option to show cve(s) of a specific package only

[RobertBerger]

It would be interesting to see how many cve(s) are contained in a single package e.g. the kernel, since those will be the majority of all cve(s). Would it be easy for you to add such a feature?

[RobertBerger]

of course I could also do it like that:

python3 cve-parser.py -f /workdir/build/multi-v7-ml-debug-training-master/tmp/log/cve/cve-summary.json -u | grep linux-yocto-custom | wc -l 871

python3 cve-parser.py -f /workdir/build/multi-v7-ml-debug-training-master/tmp/log/cve/cve-summary.json -u -e Extra stats: Total displayed issues: 879

and as you can see most are from the kernel

[RobertBerger]

if I go from 6.6.22 to 6.6.58:

./unpached-from-one-package.sh linux-yocto-custom package: linux-yocto-custom unpatched CVEs: 216

[ejaaskel]

That sounds like a good feature. I'll investigate how it could be added. It at least does not sound too difficult

[ejaaskel]

Added this in pull request #3

[RobertBerger]

This looks good to me. Thanks!

With a 6.12-rc6 kernel:

$ ./cve-parser.py -f /workdir/build/multi-v7-ml-debug-training-master/tmp/log/cve/cve-summary.json -u -dp linux-yocto-custom -e
linux-yocto-custom CVE-1999-0524     2.1      0.0      Unpatched  https://nvd.nist.gov/vuln/detail/CVE-1999-0524     
linux-yocto-custom CVE-1999-0656     5.0      0.0      Unpatched  https://nvd.nist.gov/vuln/detail/CVE-1999-0656    
...
linux-yocto-custom CVE-2024-0193     0.0      6.7      Unpatched  https://nvd.nist.gov/vuln/detail/CVE-2024-0193     
linux-yocto-custom CVE-2024-38381    0.0      7.1      Unpatched  https://nvd.nist.gov/vuln/detail/CVE-2024-38381    
linux-yocto-custom CVE-2024-50067    0.0      7.8      Unpatched  https://nvd.nist.gov/vuln/detail/CVE-2024-50067    

Extra stats:
Total displayed issues: 88

879 -> 216 -> 88

Now I'll see how it's possible to check which can be removed from those because they are not compiled due to CONFIG settings.

[RobertBerger]

Hmm it seems to be easier than expected even without checking CONFIG it seems false positives are reported, since

# linux-yocto-custom CVE-2024-38381    0.0      7.1      Unpatched  https://nvd.nist.gov/vuln/detail/CVE-2024-38381
# It is patched here: git show 017ff397624930fd7ac7f1761f3c9d6a7100f68c
CVE_STATUS[CVE-2024-38381] = "fixed-version: Fixed from version 6.9.4"

# linux-yocto-custom CVE-2024-50067    0.0      7.8      Unpatched  https://nvd.nist.gov/vuln/detail/CVE-2024-50067
# It is patched here: git show 373b9338c9722a368925d83bc622c596896b328e
# CVE_CHECK_IGNORE += "CVE-2024-50067"

CVE_STATUS[CVE-2024-50067] = "fixed-version: Fixed from version 6.12"

[ejaaskel]

Yes, this program doesn't really know which kernel CVEs are actually compiled in and which are not (that would be a really useful feature though). This program is mainly for formatting the information that the Yocto's CVE parser reports.

And indeed like you mentioned, if you find out what issues are false positives you can add them to CVE_CHECK_IGNORE variable in Yocto build and they shouldn't appear in further reports, and therefore this program shouldn't output them either.

[RobertBerger]

An interesting article[1] describes triaging based on the max suite[2]. I tried out koverage based on my config, but it does not work as expected. It shows, that although I did not include CONFIG_TLS in my config the vulnerable code is included, which can not be. So I am wondering what I am doing wrong. In this case, compiling the kernel and no tls code being built should be sufficient to exclude the CVE.

# linux-yocto-custom CVE-2023-6240     0.0      6.5      Unpatched  https://nvd.nist.gov/vuln/detail/CVE-2023-6240
#
# https://security.access.redhat.com/data/csaf/v2/advisories/2024/rhsa-2024_1881.json
# {
#         "category": "other",
#         "text": "Red Hat Enterprise Linux 6 and 7 are not affected by this CVE as they did not include kernel TLS support (upstream commit 3c4d755). Red Hat Enterprise Linux 8 is not affected as it did not include the upstream commit that introduced this flaw (fd31f39 \"tls: rx: decrypt into a fresh skb\").",
#         "title": "Statement"
#       },
#
# git show 3c4d7559159bfe1e3b94df3a657b2cda3a34e218
# git tag --contains 3c4d7559159bfe1e3b94df3a657b2cda3a34e218
#
# more explanation:
# https://people.redhat.com/~hkario/marvin/
#
# https://osv.dev/vulnerability/CVE-2023-6240
# no fix available
#
# https://security-tracker.debian.org/tracker/CVE-2023-6240
# unfixed
#
# I guess I could argue here, that I do not include TLS support in the kernel
# CONFIG_TLS is not set
CVE_STATUS[CVE-2023-6240] = "not-applicable-config: CONFIG_TLS is not set"

[1] https://www.miraxia.com/en/engineers-blog/config-based-cve-matching-for-linux-kernel/ [2] https://github.com/paulgazz/kmax

[RobertBerger]

On the 6.12-rc6 kernel I am down to 1 CVE ;)

linux-yocto-custom CVE-2019-14899    4.9      7.4      Unpatched  https://nvd.nist.gov/vuln/detail/CVE-2019-14899

since I'm not quite sure how to deal with this one. It's not clear if/how it's fixed upstream.

Here[1] is some interesting info about it.

[1] https://marc.info/?l=oss-security&s=CVE-2019-14899

[ejaaskel]

Hmm, that's a bit of an odd issue. If I understood right, it's not really operating system specific, and it hasn't been fixed. Did you find a way of filtering out the issues that weren't actually built in, like the CONFIG_TLS you mentioned in the earlier comment?

[RobertBerger]

Most of it turned out easier than expected. I just looked at the kernel .config to resolve things.

# linux-yocto-custom CVE-2023-6240     0.0      6.5      Unpatched  https://nvd.nist.gov/vuln/detail/CVE-2023-6240
#
# https://ubuntu.com/security/CVE-2023-6240
# appears unfixed in upstream as of 2024.08.24
# 
# https://security.access.redhat.com/data/csaf/v2/advisories/2024/rhsa-2024_1881.json
# {
#         "category": "other",
#         "text": "Red Hat Enterprise Linux 6 and 7 are not affected by this CVE as they did not include kernel TLS support (upstream commit 3c4d755). Red Hat Enterprise Linux 8 is not affected as it did not include the upstream commit that introduced this flaw (fd31f39 \"tls: rx: decrypt into a fresh skb\").",
#         "title": "Statement"
#       },
#
# git show 3c4d7559159bfe1e3b94df3a657b2cda3a34e218
# git tag --contains 3c4d7559159bfe1e3b94df3a657b2cda3a34e218
#
# more explanation:
# https://people.redhat.com/~hkario/marvin/
#
# https://osv.dev/vulnerability/CVE-2023-6240
# no fix available
#
# https://security-tracker.debian.org/tracker/CVE-2023-6240
# unfixed
#
# I guess I could argue here, that I do not include TLS support in the kernel
# CONFIG_TLS is not set
CVE_STATUS[CVE-2023-6240] = "not-applicable-config: CONFIG_TLS is not set"

# linux-yocto-custom CVE-2016-3695     2.1      5.5      Unpatched  https://nvd.nist.gov/vuln/detail/CVE-2016-3695
# 
# https://git.launchpad.net/ubuntu-cve-tracker/tree/active/CVE-2016-3695
# does not exist
#
# https://ubuntu.com/security/CVE-2016-3695
# break-fix: https://git.kernel.org/linus/local-lockdown - https://git.kernel.org/linus/local-2016-3695-1
# This CVE was assigned against an out-of-tree patch series.
#
# https://security-tracker.debian.org/tracker/CVE-2016-3695
# The einj_error_inject function in drivers/acpi/apei/einj.c in the Linux kernel allows local users to simulate
# hardware errors and consequently cause a denial of service by leveraging failure to disable APEI error injection through EINJ when securelevel is set.
# [jessie] - linux <not-affected> (Vulnerable code not present)
# [wheezy] - linux <not-affected> (Vulnerable code not present)
#
# https://github.com/mjg59/linux/commit/d7a6be58edc01b1c66ecd8fcc91236bfbce0a420
# drivers/acpi/apei/einj.c
# 
CVE_STATUS[CVE-2016-3695] = "not-applicable-config: CONFIG_ACPI is not set"