GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux x86/mce: broken copy-from-user fixup turns a recoverable memory error into a host panic

CVSS 5.5CVE-2025-39989Kernel, userspace & hypervisorcurated

Impact

Since 5.17 the extable fixup type for copy-from-user changed from EX_TYPE_UACCESS to EX_TYPE_EFAULT_REG, so the machine-check handler no longer recognized get_user()/copy_from_user() as a recoverable copy-from-user context. Consuming an uncorrected memory error there panics the kernel instead of returning -EFAULT to the faulting process; a second regression in the series kills user processes with SIGBUS on a CMCI/MCE race during instruction fetch. This is a fleet-reliability issue rather than an attacker capability: on GPU nodes with hundreds of gigabytes of DRAM, single-bit uncorrected errors are routine, and a kernel that panics on each one loses every co-resident job instead of killing one task. The record describes it as a regression against 5.10 behaviour.

Who can reach it

No network or tenant attack path is described in the record. The trigger is hardware: an uncorrected memory error consumed while the kernel is copying from user memory, or during user-space instruction fetch. Any workload touching poisoned memory on an affected kernel can bring the node down.

What to do

Take the stable kernel update that restores is_copy_from_user()-based detection in the MCE handler (five stable commits are linked in the record; no fixed release numbers are given there). That means draining and rebooting each node, which on a GPU fleet is best folded into an existing maintenance rotation rather than scheduled urgently - there is no tenant-reachable exploit, only worse behaviour when DRAM fails.

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.