Missing Linux kernel mitigations for hardware vulnerabilities is a Greenbone/OpenVAS finding that means the running kernel reports one or more CPU flaws (Spectre, Meltdown, MDS, iTLB multihit and similar) as unmitigated, or cannot report their status at all. Fix it by updating the kernel and CPU microcode, removing boot parameters such as mitigations=off, regenerating GRUB and rebooting.
What the scanner is actually detecting
Greenbone does not ship this as a single test. It is a family of NVTs in the OpenVAS feed, one per vulnerability class, with titles that follow the pattern Missing Linux Kernel mitigations for ‘<name>’ hardware vulnerabilities. Two members you will commonly see:
- OID 1.3.6.1.4.1.25623.1.0.108766: Missing Linux Kernel mitigations for ‘iTLB multihit’ hardware vulnerabilities (CVE-2018-12207).
- OID 1.3.6.1.4.1.25623.1.0.108767: Missing Linux Kernel mitigations for hardware vulnerabilities (sysfs interface not available). This one fires when the kernel does not expose a status interface at all, and Greenbone then assumes the host lacks every mitigation.
All of them are authenticated checks. Over SSH, the scanner reads each file under /sys/devices/system/cpu/vulnerabilities/ and prints a table of the file checked and the kernel’s answer. According to the kernel’s sysfs ABI documentation, each file contains one of three kinds of value: Not affected, Vulnerable, or Mitigation: <name>. Greenbone flags a file that says Vulnerable, and it also flags a file that is missing while the directory exists, reasoning that the kernel does not know about that vulnerability yet and therefore cannot mitigate it. The NVT’s own solution is to enable the mitigation in the kernel or move to a newer kernel. The members we reviewed are rated Medium.
Real-world risk
These are CPU design flaws, not bugs in a network service. Nearly all of them require the attacker to already run code on the same physical processor: a local user, a compromised process, a container, or a guest VM on the same hypervisor. Most (Spectre, Meltdown, MDS and relatives) can leak memory across privilege or VM boundaries. iTLB multihit is different: the kernel documentation describes it as a way for a malicious guest to trigger a machine check on a KVM host, which is a denial of service, not a data leak. None of them gives remote code execution on its own.
Prioritize by host role. KVM and other virtualization hosts, multi-user shell servers, CI runners and anything executing code you do not fully trust carry the real exposure. A single-purpose server running only vetted software has much lower practical risk, but the finding still marks a hardening gap auditors will ask about.
How to confirm it on the host
Read what the running kernel reports. The grep . form prints each file name next to its contents:
uname -r
grep . /sys/devices/system/cpu/vulnerabilities/*Check whether a boot parameter is switching mitigations off. Every parameter in this pattern is listed in the kernel documentation as part of what mitigations=off disables, or as an equivalent:
cat /proc/cmdline
grep -oE 'mitigations=[^ ]+|nopti|pti=off|nospectre_v[12]|spectre_v2=off|nospec_store_bypass_disable|spec_store_bypass_disable=off|(mds|l1tf|tsx_async_abort|mmio_stale_data|retbleed|srbds|gather_data_sampling|spectre_bhi|reg_file_data_sampling|spec_rstack_overflow)=off|kvm.nx_huge_pages=off' /proc/cmdlineCheck the loaded microcode revision and whether this is a VM:
grep -m1 microcode /proc/cpuinfo
journalctl -b -k | grep "microcode:"
systemd-detect-virtOn a custom-built kernel, confirm the mitigations were compiled in. The kernel documentation notes that mitigations= is only supported when the kernel is built with CPU_MITIGATIONS=y (older kernels used the name SPECULATION_MITIGATIONS):
grep -E 'CPU_MITIGATIONS|SPECULATION_MITIGATIONS' /boot/config-$(uname -r)How to read common results:
| What you see | Usual cause |
|---|---|
| Vulnerable, and a matching parameter in /proc/cmdline | Mitigation disabled at boot |
| Vulnerable: Clear CPU buffers attempted, no microcode (mds) | Microcode update missing |
| Vulnerable in old_microcode (recent kernels) | Microcode older than the kernel’s table of released revisions |
| KVM: Vulnerable in itlb_multihit | KVM mitigation off, which matters only on hosts running guests |
| A file missing that newer kernels provide | Kernel too old to know that vulnerability |
| The whole directory missing | Very old or unusual kernel (the 108767 case) |
How to fix it
Step 1: update the kernel and CPU microcode
On Debian and Ubuntu, install current kernel updates and the vendor microcode package. On Debian 12 and later the microcode packages live in the non-free-firmware component, which must be enabled in your APT sources:
sudo apt update
sudo apt full-upgrade
sudo apt install intel-microcode # Intel CPUs
sudo apt install amd64-microcode # AMD CPUsOn RHEL and compatible distributions, Red Hat ships Intel microcode in microcode_ctl and AMD microcode in linux-firmware. A full update brings the kernel and both packages current:
sudo dnf upgrade --refresh
rpm -q kernel microcode_ctl linux-firmwareThe Debian wiki also recommends applying the hardware vendor’s BIOS or UEFI update, which carries its own microcode. On virtual machines, the Linux microcode loader turns itself off when it detects a hypervisor, so microcode has to be updated on the host. Patch the hypervisor first, then the guests.
Step 2: remove parameters that disable mitigations (Debian, Ubuntu)
Back up the GRUB defaults, then delete mitigations=off and any of the other parameters found above from GRUB_CMDLINE_LINUX_DEFAULT and GRUB_CMDLINE_LINUX. Check the drop-in directory too, since cloud images often set the command line there:
sudo cp /etc/default/grub /etc/default/grub.bak
grep -rnE 'mitigations=|nopti|nospectre|nospec_store' /etc/default/grub /etc/default/grub.d/ 2>/dev/null
sudoedit /etc/default/grub
sudo update-grubStep 3: remove parameters that disable mitigations (RHEL 8, 9, 10)
RHEL uses Boot Loader Specification entries managed by grubby. List the current arguments, then remove the offending ones from every installed kernel:
sudo grubby --info=ALL | grep -E '^(kernel|args)'
sudo grubby --update-kernel=ALL --remove-args="mitigations=off"Repeat –remove-args for any other parameter you found. Red Hat notes that grubby changes the boot entries but not /etc/default/grub, so also remove the parameter from GRUB_CMDLINE_LINUX there; otherwise a later grub2-mkconfig run can bring it back. On RHEL 9, Red Hat documents grub2-mkconfig -o /boot/grub2/grub.cfg –update-bls-cmdline to sync that file into the boot entries.
Step 4: KVM hosts and iTLB multihit
The KVM mitigation is controlled by kvm.nx_huge_pages. Its default, auto, enables the mitigation when the CPU is affected and the kernel was not booted with mitigations=off. Confirm it is not forced off:
cat /sys/module/kvm/parameters/nx_huge_pagesIf it reads off, remove kvm.nx_huge_pages=off from the command line (steps 2 or 3) and any options kvm nx_huge_pages=off line under /etc/modprobe.d/.
Step 5: reboot
Microcode is applied at boot and the kernel decides its mitigations at boot, so nothing changes until the host restarts. Batch this with the kernel update in a planned window; our guide to reboot orchestration for patching covers sequencing clustered and dependent hosts. For VMs, a full shutdown and start (not an in-guest reboot) is often needed before a guest sees CPU features added on the host; follow your hypervisor vendor’s guidance.
How to verify the fix and rescan
After the reboot, confirm the parameters are gone and list any file that does not report Not affected or a Mitigation. No output from the second command means the kernel considers every listed issue handled:
cat /proc/cmdline
grep -L -E 'Not affected|Mitigation' /sys/devices/system/cpu/vulnerabilities/*Then rerun the same credentialed OpenVAS scan. The NVTs read sysfs from the running kernel, so a scan taken before the reboot will still show the finding even though the packages are installed.
What can break and how to roll back
- Performance. The kernel documentation describes mitigations=off as improving performance at the cost of exposure, so turning mitigations back on costs some throughput. The effect depends on CPU model and workload; measure on a representative host before a fleet rollout.
- SMT. The default (mitigations=auto) keeps Hyper-Threading on even where it is vulnerable, so some files may read Mitigation with an “SMT vulnerable” suffix. mitigations=auto,nosmt closes that gap but disables SMT when needed, removing logical CPUs. Choose it deliberately.
- Microcode boot problems. The Debian wiki notes that, very rarely, a microcode update can cause hangs early in boot. The dis_ucode_ldr parameter, added once from the GRUB menu, skips microcode loading so you can recover.
- Kernel regressions. Keep the previous kernel installed and pick it under Advanced options in the GRUB menu, or on RHEL set it with grubby –set-default.
- Undoing the parameter change. Restore /etc/default/grub.bak and run update-grub, or on RHEL re-add it with grubby –update-kernel=ALL –args=”mitigations=off”. That is a documented risk acceptance, not a fix.
Common false positive reasons
- Scanned before reboot. Updated packages do not change sysfs until the new kernel and microcode are loaded.
- VM guests. A guest’s status depends on what the host’s microcode and hypervisor expose. The mds file shows “SMT Host state unknown” inside VMs, and published cloud cases show guests reporting Vulnerable until the provider exposes the needed CPU features. Resolve on the host, or record an exception with the provider’s advisory.
- iTLB multihit without guests. The kernel documentation says systems not using virtualization need no action. “KVM: Vulnerable” on a host that runs no VMs, or “Processor vulnerable” from a kernel built without Intel KVM support, is low risk and can be accepted with that note.
- Sysfs not readable. The 108767 result can come from a scan account or restricted environment that could not read /sys, not only from an old kernel. Run the commands above manually before replacing anything.
Unlike version-based kernel NVTs, this family reads the kernel’s own report, so distribution backports do not explain it away. For kernel findings that compare package versions, see why backported patches trigger false positives.
FAQ
Is installing intel-microcode or amd64-microcode enough?
Not until the host reboots. Microcode is loaded at boot, and the kernel must also be new enough to use it and not be booted with mitigations disabled.
Is mitigations=off ever acceptable?
It is a documented option for hosts that run only trusted code where performance matters more. Treat it as a recorded exception with an owner, not as the normal configuration.
Do I need to disable Hyper-Threading?
No. The default keeps SMT on while mitigating everything else. Consider mitigations=auto,nosmt only where untrusted code or tenants share physical cores.
Why does the finding remain on my cloud VM after patching?
The guest cannot load microcode, and some mitigations need CPU features the hypervisor must expose. Check the provider’s security advisory and document the exception if the host side is their responsibility.
Tracking this finding across many hosts
Because this finding needs kernel updates, microcode, boot parameter cleanup and a reboot, it tends to linger on a few hosts after the bulk rollout. SITEY, a self-hosted vulnerability management platform, can launch OpenVAS scans directly to recheck hosts after the maintenance window, and its AI triage can suggest likely false positives, such as VM guests, with evidence for a human to decide. It can also draft host-specific remediation scripts that run only after human approval, deployed through its agents on Linux endpoints.