CVE-2026-64326 Overview
CVE-2026-64326 is a Linux kernel vulnerability in the block layer's bdev_mark_dead() function. The flaw causes the kernel to call sync_blockdev() unconditionally during surprise device removal, even when the underlying device is already gone. This behavior can wedge the kernel indefinitely inside folio_wait_writeback(), waiting on writeback that can never complete.
The issue was discovered through FuzzNvme, a syzkaller-based fuzzer built on the FEMU framework. It surfaced via the nvme_reset_work() "I/O queues lost" path, hanging the reset worker and every task blocked on it.
Critical Impact
Local denial of service through kernel task hangs during NVMe reset or surprise storage removal, stalling all dependent I/O operations.
Affected Products
- Linux kernel versions containing the bdev_mark_dead() holder callback wiring change referenced in the Fixes tag
- Systems using NVMe storage subject to nvme_reset_work() recovery paths
- Any block device consumer without a custom ->mark_dead operation
Discovery Timeline
- 2026-07-25 - CVE-2026-64326 published to the National Vulnerability Database (NVD)
- 2026-07-25 - Last updated in NVD database
Technical Details for CVE-2026-64326
Vulnerability Analysis
The vulnerability resides in the Linux kernel block layer function bdev_mark_dead(). The function accepts a surprise boolean parameter indicating whether the device disappeared without orderly teardown. When surprise == true, the device is already gone and any attempt to flush dirty data is doomed to block forever.
The filesystem callback fs_bdev_mark_dead() correctly honors this contract by skipping sync_filesystem() on surprise removal. However, the bare block device path, which runs when no holder ->mark_dead operation is registered, lost its !surprise guard when the holder callback was wired up. As a result, sync_blockdev() executes unconditionally.
This mismatch causes the kernel to enter folio_wait_writeback() on pages whose writeback can no longer complete because the underlying hardware is unreachable. The waiting thread never returns, wedging the entire code path.
Root Cause
The root cause is a missing !surprise guard in the bare block device removal path inside bdev_mark_dead(). The guard existed before the holder ->mark_dead callback refactor but was inadvertently dropped. This creates a race between physical device disappearance and pending writeback completion in the page cache.
Attack Vector
The issue is triggered by hardware conditions rather than a remote attacker. Any event that causes NVMe reset with lost I/O queues, such as controller failure, surprise hotplug removal, or firmware faults, can invoke nvme_mark_namespaces_dead(), which calls blk_mark_disk_dead() and then bdev_mark_dead(bdev, true). The resulting hang blocks the reset worker and cascades to every task waiting on the affected block device.
The vulnerability was discovered through fuzzing with FuzzNvme (syzkaller combined with FEMU), demonstrating that malformed NVMe controller state can reliably reach the vulnerable path. See the kernel patch commit for the exact code change.
Detection Methods for CVE-2026-64326
Indicators of Compromise
- Kernel tasks stuck in D state with stacks showing folio_wait_writeback called from sync_blockdev and bdev_mark_dead
- Hung task warnings in dmesg referencing nvme_reset_work or blk_mark_disk_dead
- NVMe controller reset events followed by unresponsive block I/O to the affected namespaces
Detection Strategies
- Monitor kernel logs for hung_task_timeout_secs messages that name block layer or NVMe reset functions in the call trace
- Correlate NVMe AER events and controller resets with subsequent I/O stalls on the same device
- Track processes accumulating in uninterruptible sleep against storage mount points
Monitoring Recommendations
- Enable CONFIG_DETECT_HUNG_TASK and forward hung task logs to a central log store for alerting
- Instrument nvme_reset_work completion counters and alert when reset attempts fail to complete within expected windows
- Track writeback backlog metrics from /proc/meminfo (Writeback, Dirty) for anomalous growth during storage failure events
How to Mitigate CVE-2026-64326
Immediate Actions Required
- Apply the upstream kernel patches referenced by the CVE across affected stable branches
- Rebuild and deploy custom kernels that include the !surprise guard restoration in bdev_mark_dead()
- Prioritize patching on hosts with NVMe storage that experience controller resets or use hotplug drives
Patch Information
The fix skips sync_blockdev() when surprise == true, matching the behavior of fs_bdev_mark_dead(). The call to invalidate_bdev() still runs, and orderly removal (surprise == false) remains unchanged. Backport commits are available at 49f06cff50a4, 9818bcae3c0c, aa4c4a931576, d6998ddd507c, and f41cf35ee2a1.
Workarounds
- No configuration-based workaround exists; the guard must be reintroduced in kernel source
- Reduce exposure by avoiding surprise removal of NVMe devices and ensuring controllers are drained before power events
- Where feasible, use redundant storage paths (multipath, RAID) so a single controller reset does not stall dependent workloads
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
