8.10 - OVAL report not consistent with dnf

System: 8.10 x86_64, uname -r “4.18.0-553.34.1.el8_10.x86_64”

Problem: OVAL report says I have vulnerabilities that need to be patched, yet dnf commands show “Nothing to do.” This happens whether I execute commands with sudo or as root.

Reproducible: Yes.

Steps to Reproduce:

  1. sudo dnf update
  2. sudo dnf install openscap-utils scap-security-guide
  3. curl -v https://security.almalinux.org/oval/org.almalinux.alsa-8.xml.bz2 -o org.almalinux.alsa-8.xml.bz2
  4. bzip2 -d org.almalinux.alsa-8.xml.bz2
  5. oscap oval eval --results /tmp/alsa-results-oval.xml report/alsa-report-oval.html org.almalinux.alsa-8.xml

What should happen: The Result column in the alsa-report-oval.html file should only have the word false, indicating everything has been patched.

What does happen: There are some entries where the Result column in the alsa-report-oval.html file has the word true, indicating unpatched vulnerabilities.

Other information: When I run sudo dnf update, sudo dnf upgrade-minimal, and sudo dnf upgrade, dnf always shows “Dependencies resolved. Nothing to do. Complete!”

Which is it? Is there truly nothing to do and my installation is up to date and secure? Do I have the vulnerabilities that the oscap oval eval command listed in its report?

Thanks for reading!

Can you show the details on one stated vulnerability?

yup, need to see examples. if its all kernel-related, that’s because you can have multiple kernels installed

These are the vulnerabilities that are being flagged.
ALSA-2025:0065
ALSA-2024:8856
ALSA-2024:7000
ALSA-2024:5101
ALSA-2024:4211
ALSA-2024:3618
ALSA-2024:10943
ALSA-2024:10281

Those are all about the kernel, and issues that have been fixed in the latest kernel.
If you do have that, 4.18.0-553.34.1.el8_10 installed and are running it, then none of the CVEs listed are a problem.

the “solution” is to remove the older kernels and just keep the running one.

that’s pretty dangerous (and complicated) so you have to live with it and explain to the auditor. you could reduce the number of kept kernels to 2 instead of 3…

there’s some discussion around limiting the check to the running kernel, but then you could reboot into an earlier vulnerable kernel and be unaware of the risk until you scanned again.

I found the other kernel that is causing the OVAL report to show vulnerabilities.
ls -ll -h -a of /boot

You have two kernels installed, 4.18.0-553.el8_10 and 4.18.0-553.34.1.el8_10:

11M Jan  4 19:41 vmlinuz-0-rescue-25a3c113ce184a1180ff3657da7b3ba0
11M Jan  8 09:49 vmlinuz-4.18.0-553.34.1.el8_10.x86_64
11M May 24  2024 vmlinuz-4.18.0-553.el8_10.x86_64

You have installed the system on Jan 4, and package dracut-config-rescue did create the vmlinuz-0-rescue then. The rescue kernel is basically a copy (of 4.18.0-553.el8_10), but with different initramfs (that you see to be much larger).

Then you have installed updates (between Jan 8 and Jan 17), which did add the 4.18.0-553.34.1.el8_10 that you should now be using.


You can list the installed kernel packages with:

dnf rq --installonly

and list all but latest installed kernel packages with:

dnf rq --installonly --latest=-1

(That should list only the 4.18.0-553.el8_10 packages.)

You could remove those packages with:

dnf remove $(dnf rq --installonly --latest=-1)

That will leave 4.18.0-553.34.1.el8_10 and the rescue kernel.
(If you are currently running 4.18.0-553.el8_10 then it should refuse to remove.)


The rescue kernel is not from packages, so it has to be removed manually:

rm /boot/*rescue* /boot/loader/entries/*rescue*

When you install next kernel, the dracut-config-rescue should create a new rescue as copy of that kernel.

As already said, having more than one (functional) kernel is a safety measure. If something happens to current kernel, making it unbootable, then there is a fall-back.

One can also boot the machine with the installer image. There is troubleshoot option in addition to the install. With that one can also do rescue on unbootable system.

1 Like

Hello jlehtone,

Your commands worked as described. The OVAL report now shows no vulnerabilities to patch.

Thank you for the guidance.