Linux kernel virtio: devices are not reset on shutdown, hanging kexec and poking guest memory after IOMMU teardown

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

Impact

virtio devices were left live across system shutdown, so drivers such as virtio-console kept writing to MMIO after the underlying virtio-pci device was reset, and devices kept touching guest memory after the IOMMUs had already been torn down - QEMU logged rejected reads and writes and the guest hung. The operator-visible failure is a VM that will not kexec and some devices left wedged, which matters wherever the GPU fleet's management or tenant VMs are rebooted fast via kexec instead of a full reboot: a hung kexec turns a seconds-long reboot into manual recovery of the guest. Availability impact in the guest; the record describes no escape or cross-guest access.

Who can reach it

Reached by the shutdown/kexec path of a guest using virtio devices, so it is triggered by whoever can reboot or kexec the VM - normally the guest's own root, not an outside attacker. Not remotely reachable.

What to do

Update the guest kernel to a version with the fix (the linked commits break and then reset all virtio devices on virtio bus shutdown) and reboot the guest; the host side needs nothing. Until then, avoid kexec in affected guests and use a full reboot, which is the available mitigation the record supports.

References

https://nvd.nist.gov/vuln/detail/CVE-2025-38064 https://git.kernel.org/stable/c/8bd2fa086a04886798b505f28db4002525895203 https://git.kernel.org/stable/c/aee42f3d57bfa37b2716df4584edeecf63b9df4c

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.