Add support for RHEL EUS
What happened: Redhat has issued a new kernel 5.14.0-427.50.2.el9_4 which fixes the CVE
What you expected to happen: Grype should not report the issue as High on the fixed kernel
How to reproduce it (as minimally and precisely as possible): Install Kernel [kernel-headers-5.14.0-427.50.2.el9_4.x86_64.rpm]
Anything else we need to know?:
kernel 5.14.0-427.50.2.el9_4 0:5.14.0-503.23.2.el9_5 rpm CVE-2024-53104 High
kernel-core 5.14.0-427.50.2.el9_4 0:5.14.0-503.23.2.el9_5 rpm CVE-2024-53104 High
kernel-modules 5.14.0-427.50.2.el9_4 0:5.14.0-503.23.2.el9_5 rpm CVE-2024-53104 High
kernel-modules-core 5.14.0-427.50.2.el9_4 0:5.14.0-503.23.2.el9_5 rpm CVE-2024-53104 High
kernel-tools 5.14.0-427.50.2.el9_4 0:5.14.0-503.23.2.el9_5 rpm CVE-2024-53104 High
kernel-tools-libs 5.14.0-427.50.2.el9_4 0:5.14.0-503.23.2.el9_5 rpm CVE-2024-53104 High
kernel-uki-virt 5.14.0-427.50.2.el9_4 0:5.14.0-503.23.2.el9_5 rpm CVE-2024-53104 High
python3-perf 5.14.0-427.50.2.el9_4 0:5.14.0-503.23.2.el9_5 rpm CVE-2024-53104 High
High or Critical vulnerabilities exist in grype report!
Environment:
- Output of
grype version: Latest Available - OS (e.g:
cat /etc/os-releaseor similar): RHEL 9.4
The package was delivered vis Redhat extended update support EUS.
Hi @pkeecom thanks for the issue! I'll do some digging and get back to you.
The fixed version showing in grype output is from https://access.redhat.com/errata/RHSA-2025:1262, which is listed as the RHEL 9 fix for the CVE at https://access.redhat.com/security/cve/cve-2024-53104, so I think the issue is that Grype is treating the image as regular RHEL 9, not as RHEL 9.4 EUS.
Hi @pkeecom can you give us one bit of additional information about the image you are scanning? What are the contents of /etc/os-release and /etc/redhat-release?
@willmurphyscode
`cat /etc/os-release NAME="Red Hat Enterprise Linux" VERSION="9.4 (Plow)" ID="rhel" ID_LIKE="fedora" VERSION_ID="9.4" PLATFORM_ID="platform:el9" PRETTY_NAME="Red Hat Enterprise Linux 9.4 (Plow)" ANSI_COLOR="0;31" LOGO="fedora-logo-icon" CPE_NAME="cpe:/o:redhat:enterprise_linux:9::baseos" HOME_URL="https://www.redhat.com/" DOCUMENTATION_URL="https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9" BUG_REPORT_URL="https://issues.redhat.com/"
REDHAT_BUGZILLA_PRODUCT="Red Hat Enterprise Linux 9" REDHAT_BUGZILLA_PRODUCT_VERSION=9.4 REDHAT_SUPPORT_PRODUCT="Red Hat Enterprise Linux" REDHAT_SUPPORT_PRODUCT_VERSION="9.4"
[root@myhost~] $ cat /etc/redhat-release Red Hat Enterprise Linux release 9.4 (Plow)`
Yeah @willmurphyscode I'm fairly certain this is going to require querying and surfacing the enabled rpm repos in syft, it isn't going to be in the distro files. https://www.redhat.com/en/blog/how-update-red-hat-enterprise-linux-tvia-minor-releases-and-extended-update-support might help some
I thought we had a syft issue about this. I know @wagoodman and I have discussed it many times. It might be captured some in https://github.com/anchore/syft/issues/2549, but I thought there was a more specific one somewhere
@willmurphyscode @westonsteimel I don't think there's a reliable way of determining if it is under EUS or not. We mirror repos - so it may not have the word "eus" in the repo name either.
May be a setting in grype yaml or a command line option for a user to set if it is EUS or not?
Any movement on this @willmurphyscode ? It's a bit tedious trying to add CVEs to ignore list as more and more CVEs are being flagged with every run. Is there a workaround?
Hi @pkeecom,
I'm planning to pick this up next. I like the idea of providing a config option that lets users specify that they're scanning a -eus image. We'll also need to do some data work on the backend to get EUS fix versions into grype's database.
At present, I don't believe there's a great workaround.
Thanks @willmurphyscode . Looking forward to the fix.
@willmurphyscode Thanks for the fix. What's the ETA for this, please?
@willmurphyscode Sorry to bother you again. The pull requests you've linked does not seem to have moved much. When do you think this is likely to get released?
Hi @pkeecom those are still a work in progress. I don't have an exact timeline to commit to, but we are still working on this issue.
@wagoodman @willmurphyscode Thanks for 0.97 release. I tried it but there is no improvement unfortunately. My grype config has:
fix-channel:
redhat-eus:
# whether fixes from this channel should be considered, options are "never", "always", or "auto" (conditionally applied based on SBOM data) (env: GRYPE_FIX_CHANNEL_REDHAT_EUS_APPLY)
apply: 'always'
# (env: GRYPE_FIX_CHANNEL_REDHAT_EUS_VERSIONS)
versions: '>= 8.0'
The output says:
[0001] DEBUG using channel "eus" for distro "rhel" with version "9.4 (Semantic)"
[0001] INFO using distro: rhel 9.4+eus
The results have a lot of old CVEs that were fixed in EUS. Example:
NAME INSTALLED FIXED IN TYPE VULNERABILITY SEVERITY EPSS RISK
kernel 5.14.0-427.79.1.el9_4 0:5.14.0-503.23.2.el9_5 rpm CVE-2024-53104 High 2.1% (83rd) 77.7 (kev)
kernel-core 5.14.0-427.79.1.el9_4 0:5.14.0-503.23.2.el9_5 rpm CVE-2024-53104 High 2.1% (83rd) 77.7 (kev)
My installed kernel:
rpm -qa |grep kernel-core
kernel-core-5.14.0-427.79.1.el9_4.x86_64
This was fixed by Redhat in:
https://access.redhat.com/errata/RHSA-2025:1270
kernel-5.14.0-427.50.2.el9_4.src.rpm | SHA-256: 2a68cc01b0bea09cc2c3d5d74ad29697ded504488bc25af1578d01ea3bae636f
The OS:
cat /etc/os-release
NAME="Red Hat Enterprise Linux"
VERSION="9.4 (Plow)"
ID="rhel"
ID_LIKE="fedora"
VERSION_ID="9.4"
PLATFORM_ID="platform:el9"
PRETTY_NAME="Red Hat Enterprise Linux 9.4 (Plow)"
....
Please advise. Also, I note that changing 'apply' to never or auto or always in .grype.yml has no effect. I always see the debug message that it is applying EUS.