CVE-2025-38064

Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source

AV:LAttack vector, local

The vulnerable path is `device_shutdown()`, reached only through local reboot/halt/kexec syscalls in `kernel/reboot.c`; no network or adjacent-network input reaches the virtio bus shutdown code. The impact lands on the local system (guest kernel), so the vector is Local.

AC:LAttack complexity, low

The failure is deterministic rather than a race — every reboot/kexec on a system with an in-use virtio device (virtio-console, virtio-net, virtio-blk) leaves the device unquiesced, and the reporter noted kexec hangs reliably whenever virtio-console is in use. No memory-layout or timing conditions outside the attacker's control are required.

PR:LPrivileges required, low

Although `reboot()`/`kexec_load()` nominally check `CAP_SYS_BOOT`, unprivileged local users on typical desktop, embedded and appliance deployments can initiate a system reboot or power-off through logind/polkit (and Ctrl-Alt-Del reaches `ctrl_alt_del()` with no credentials at all), so a basic local user can reach `device_shutdown()`. Choosing the higher-severity option, this is Low rather than High.

UI:NUser interaction, none

The reboot/kexec that triggers the unquiesced-device window is performed by the attacker themselves; no separate victim has to open a file, mount a filesystem, or take any other action.

S:UScope, unchanged

Both the flawed code and the damage — the hang, the stray MMIO/DMA traffic, and the corruption of the newly loaded kernel image — are confined to the same kernel/guest security authority. The virtio backend that performs the stray DMA already holds authority over that memory, so no privilege boundary is crossed.

C:HConfidentiality impact, high

With virtqueues left armed and `intel_iommu_shutdown()` having already disabled translation and protected memory regions, the still-live device continues DMA *reads* from stale ring and buffer physical addresses — QEMU observed exactly this ("Invalid read at addr 0x102877002"). Those reads hand the contents of memory now owned by the kexec'd kernel to the device backend, an unbounded kernel-memory disclosure.

I:HIntegrity impact, high

The same unreset devices continue DMA *writes* into stale buffer addresses ("Invalid write at addr 0x102877A44") after DMA isolation has been torn down, so a device such as virtio-net can deposit remote-attacker-supplied packet bytes into memory that the freshly loaded kernel has repurposed for its own image and data. That is arbitrary corruption of the incoming kernel, exploitable for control-flow hijack.

A:HAvailability impact, high

The reported symptom is a hard hang of the VM on kexec — the machine never completes the boot and requires an out-of-band power cycle — and the commit further notes that devices "get wedged" once the IOMMU rejects their accesses. Complete loss of availability.