GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel x86/mce: CMCI discovery kicks the MCE polling timer before it is initialized

CVE-2026-80727Kernel, userspace & hypervisorcurated

Impact

On a CPU that comes up with an inherited CMCI storm - banks already signalling corrected machine-check errors when the kernel takes over from firmware - cmci_discover() calls mce_timer_kick() during mcheck_cpu_init(), before __mcheck_cpu_setup_timer() has run timer_setup(). The kernel arms an uninitialized timer_list, and timer_setup() then re-initializes a timer that is already queued; the record shows both DEBUG_OBJECTS splats from the reporter's machine. There is no attacker here - the trigger is the machine-check state of the hardware at boot, not anything a tenant can do - so treat this as a boot-time correctness bug in error handling, not a tenancy risk. It still matters on GPU hosts because those are exactly the machines that boot with corrected-error storms latched on memory or PCIe banks, and the MCE polling timer is what surfaces the corrected-error rate telling you an HBM stack or DIMM is degrading. The fix sets the timer up first.

Who can reach it

None reachable by an attacker: the path runs during early boot on the affected CPU and depends on machine-check bank state inherited from firmware. No authentication concept applies.

What to do

Pick this up with your normal stable-kernel cadence (e708fc1566eb and backports) and drain plus reboot nodes on the regular schedule - there is nothing to mitigate at runtime and no reason to open an emergency window for it, since a node that boots cleanly today is not exposed. Prioritize nodes that log 'CMCI inherited storm' at boot, as those are the ones actually hitting the path.

References

Related entries

All Kernel, userspace & hypervisor entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.