UBUNTU-CVE-2026-64326: Medium severity ubuntu/linux-hwe-edge vulnerability
In the Linux kernel, the following vulnerability has been resolved: block: skip syncblockdev() on surprise removal in bdevmarkdead() bdevmarkdead()'s @surprise == true means the device is already gone. The filesystem callback fsbdevmarkdead() honours this and skips syncfilesystem(), but the bare block device path (no ->markdead op) lost its !surprise guard when the holder ->markdead callback was wired up (see Fixes), and now calls syncblockdev() unconditionally, which can hang forever waiting on writeback that can no longer complete. syzkaller hit this via nvmeresetwork()'s "I/O queues lost" path: nvmemarknamespacesdead() -> blkmarkdiskdead() -> bdevmarkdead(bdev, true) -> syncblockdev() blocks in foliowaitwriteback(), wedging the reset worker and every task waiting on it. Skip the sync on surprise removal, matching fsbdevmarkdead(); invalidatebdev() still runs. Orderly removal (surprise == false) is unchanged. Found by FuzzNvme(Syzkaller with FEMU fuzzing framework).
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 6.8.0-147.147 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 6.8.0-1067.70 - Upgrade
Upgrade
ubuntu/linux-aws-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1012.12~24.04.1 - Upgrade
Upgrade
ubuntu/linux-azureto a version that resolves this vulnerability.Fixed in 6.8.0-1071.79 - Upgrade
Upgrade
ubuntu/linux-azure-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1014.14~24.04.1 - Upgrade
Upgrade
ubuntu/linux-azure-fdeto a version that resolves this vulnerability.Fixed in 6.8.0-1069.76 - Upgrade
Upgrade
ubuntu/linux-azure-fde-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1013.13~24.04.1 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 6.8.0-1071.79 - Upgrade
Upgrade
ubuntu/linux-gcp-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1011.11~24.04.1 - Upgrade
Upgrade
ubuntu/linux-gketo a version that resolves this vulnerability.Fixed in 6.8.0-1066.74 - Upgrade
Upgrade
ubuntu/linux-gkeopto a version that resolves this vulnerability.Fixed in 6.8.0-1052.56 - Upgrade
Upgrade
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-31.31~24.04.1 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 6.8.0-1067.68 - Upgrade
Upgrade
ubuntu/linux-lowlatencyto a version that resolves this vulnerability.Fixed in 6.8.0-147.147.1 - Upgrade
Upgrade
ubuntu/linux-nvidia-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1018.18~24.04.1 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 6.8.0-1064.67 - Upgrade
Upgrade
ubuntu/linux-oracle-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1011.11~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-31.31.1~24.04.1 - Upgrade
Upgrade
ubuntu/linux-bluefieldto a version that resolves this vulnerability.Fixed in 6.8.0-1033.38 - Upgrade
Upgrade
ubuntu/linux-realtimeto a version that resolves this vulnerability.Fixed in 6.8.1-1062.63 - Upgrade
Upgrade
ubuntu/linux-aws-fipsto a version that resolves this vulnerability.Fixed in 6.8.0-1067.70+fips1 - Upgrade
Upgrade
ubuntu/linux-azure-fipsto a version that resolves this vulnerability.Fixed in 6.8.0-1071.79+fips1 - Upgrade
Upgrade
ubuntu/linux-fipsto a version that resolves this vulnerability.Fixed in 6.8.0-147.147+fips1 - Upgrade
Upgrade
ubuntu/linux-gcp-fipsto a version that resolves this vulnerability.Fixed in 6.8.0-1071.79+fips1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-31.31 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1012.12 - Upgrade
Upgrade
ubuntu/linux-azureto a version that resolves this vulnerability.Fixed in 7.0.0-1014.14 - Upgrade
Upgrade
ubuntu/linux-azure-fdeto a version that resolves this vulnerability.Fixed in 7.0.0-1013.13 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1011.11 - Upgrade
Upgrade
ubuntu/linux-gketo a version that resolves this vulnerability.Fixed in 7.0.0-1006.7 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1013.13 - Upgrade
Upgrade
ubuntu/linux-nvidiato a version that resolves this vulnerability.Fixed in 7.0.0-1018.18 - Upgrade
Upgrade
ubuntu/linux-nvidia-bosto a version that resolves this vulnerability.Fixed in 7.0.0-2018.18 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1013.13 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1011.11 - Upgrade
Upgrade
ubuntu/linux-raspito a version that resolves this vulnerability.Fixed in 7.0.0-1019.19 - Upgrade
Upgrade
ubuntu/linux-realtimeto a version that resolves this vulnerability.Fixed in 7.0.0-31.31.1 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-31.31.1
Event History
Frequently Asked Questions
What systems are most likely to encounter this issue?
Affected systems are those running one of the listed Ubuntu kernel packages and experiencing surprise block-device removal. The reported trigger was an NVMe controller reset path where I/O queues were lost.
What does an attacker or triggering condition need to cause the hang?
The issue requires a local condition that causes a block device to be marked dead with surprise removal enabled. No user interaction is required, but the provided data does not identify a remote attack path.
What is the operational impact?
The kernel can wait indefinitely for writeback on a device that is already gone. This can wedge the device reset worker and tasks waiting for that worker, causing a denial of service.
Is normal, orderly device removal affected?
No. The description states that orderly removal, where surprise removal is false, is unchanged.
What happens after the fix when a device disappears unexpectedly?
The kernel skips syncing the dead block device during surprise removal while still invalidating it. This avoids waiting for writeback that can no longer complete.