{ "dataType": "CVE_RECORD", "dataVersion": "5.2", "cveMetadata": { "cveId": "CVE-2025-38064", "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "state": "PUBLISHED", "assignerShortName": "Linux", "dateReserved": "2025-04-16T04:51:23.980Z", "datePublished": "2025-06-18T09:33:42.931Z", "dateUpdated": "2026-08-05T11:59:11.657Z" }, "containers": { "cna": { "providerMetadata": { "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "shortName": "Linux", "dateUpdated": "2026-08-05T11:59:11.657Z" }, "descriptions": [ { "lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nvirtio: break and reset virtio devices on device_shutdown()\n\nHongyu reported a hang on kexec in a VM. QEMU reported invalid memory\naccesses during the hang.\n\n\tInvalid read at addr 0x102877002, size 2, region '(null)', reason: rejected\n\tInvalid write at addr 0x102877A44, size 2, region '(null)', reason: rejected\n\t...\n\nIt was traced down to virtio-console. Kexec works fine if virtio-console\nis not in use.\n\nThe issue is that virtio-console continues to write to the MMIO even after\nunderlying virtio-pci device is reset.\n\nAdditionally, Eric noticed that IOMMUs are reset before devices, if\ndevices are not reset on shutdown they continue to poke at guest memory\nand get errors from the IOMMU. Some devices get wedged then.\n\nThe problem can be solved by breaking all virtio devices on virtio\nbus shutdown, then resetting them." } ], "metrics": [ { "cvssV3_1": { "version": "3.1", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H", "baseScore": 7.8, "baseSeverity": "HIGH" }, "scenarios": [ { "lang": "en", "value": "AV:L - 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.\nAC:L - 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.\nPR:L - 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.\nUI:N - 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.\nS:U - 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.\nC:H - 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.\nI:H - 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.\nA:H - 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." } ] } ], "affected": [ { "product": "Linux", "vendor": "Linux", "defaultStatus": "unaffected", "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "programFiles": [ "drivers/virtio/virtio.c" ], "versions": [ { "version": "ec3d41c4db4c21164332826ea8d812f94f2f6886", "lessThan": "aee42f3d57bfa37b2716df4584edeecf63b9df4c", "status": "affected", "versionType": "git" }, { "version": "ec3d41c4db4c21164332826ea8d812f94f2f6886", "lessThan": "8bd2fa086a04886798b505f28db4002525895203", "status": "affected", "versionType": "git" } ] }, { "product": "Linux", "vendor": "Linux", "defaultStatus": "affected", "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "programFiles": [ "drivers/virtio/virtio.c" ], "versions": [ { "version": "2.6.24", "status": "affected" }, { "version": "0", "lessThan": "2.6.24", "status": "unaffected", "versionType": "semver" }, { "version": "6.14.9", "lessThanOrEqual": "6.14.*", "status": "unaffected", "versionType": "semver" }, { "version": "6.15", "lessThanOrEqual": "*", "status": "unaffected", "versionType": "original_commit_for_fix" } ] } ], "cpeApplicability": [ { "nodes": [ { "operator": "OR", "negate": false, "cpeMatch": [ { "vulnerable": true, "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "versionStartIncluding": "2.6.24", "versionEndExcluding": "6.14.9" }, { "vulnerable": true, "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "versionStartIncluding": "2.6.24", "versionEndExcluding": "6.15" } ] } ] } ], "references": [ { "url": "https://git.kernel.org/stable/c/aee42f3d57bfa37b2716df4584edeecf63b9df4c" }, { "url": "https://git.kernel.org/stable/c/8bd2fa086a04886798b505f28db4002525895203" } ], "title": "virtio: break and reset virtio devices on device_shutdown()", "x_generator": { "engine": "bippy-1.2.0" } } } }