CVE-2026-64326 in Linux
Summary
by MITRE • 07/25/2026
In the Linux kernel, the following vulnerability has been resolved:
block: skip sync_blockdev() on surprise removal in bdev_mark_dead()
bdev_mark_dead()'s @surprise == true means the device is already gone. The filesystem callback fs_bdev_mark_dead() honours this and skips sync_filesystem(), but the bare block device path (no ->mark_dead op) lost its !surprise guard when the holder ->mark_dead callback was wired up (see Fixes), and now calls sync_blockdev() unconditionally, which can hang forever waiting on writeback that can no longer complete.
syzkaller hit this via nvme_reset_work()'s "I/O queues lost" path: nvme_mark_namespaces_dead() -> blk_mark_disk_dead() -> bdev_mark_dead(bdev, true) -> sync_blockdev() blocks in folio_wait_writeback(), wedging the reset worker and every task waiting on it.
Skip the sync on surprise removal, matching fs_bdev_mark_dead(); invalidate_bdev() still runs. Orderly removal (surprise == false) is unchanged.
Found by FuzzNvme(Syzkaller with FEMU fuzzing framework).
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 07/25/2026
This vulnerability exists within the Linux kernel's block device subsystem where a critical synchronization issue occurs during surprise device removal scenarios. The flaw manifests in the bdev_mark_dead() function which handles marking block devices as dead, particularly when devices are unexpectedly removed from the system. When the surprise parameter is set to true, indicating that the device has already been removed, the filesystem callback fs_bdev_mark_dead() correctly skips the sync_filesystem() operation to prevent hanging. However, the underlying block device path lacks this same safeguard, creating a discrepancy in behavior that leads to system hangs.
The technical root cause stems from an inconsistent implementation where the block device path does not maintain the same conditional logic as the filesystem callback. During surprise removal conditions, the system attempts to call sync_blockdev() unconditionally, which can result in indefinite waiting for writeback operations that can no longer complete. This specific hang occurs within folio_wait_writeback() during the nvme_reset_work() execution path when nvme_mark_namespaces_dead() invokes blk_mark_disk_dead() which subsequently calls bdev_mark_dead() with surprise=true parameter. The system becomes deadlocked as the sync_blockdev() call cannot proceed due to the absent device, causing the reset worker thread and all dependent tasks to block indefinitely.
The operational impact of this vulnerability is severe particularly in storage subsystems where NVMe devices are commonly used. When an NVMe controller experiences queue loss during reset operations, the system becomes unresponsive as the reset worker thread gets stuck waiting for writeback completion that will never occur. This creates a cascading failure effect where not only does the device reset fail, but all other tasks waiting on the same resource become blocked, effectively rendering the system unstable and potentially leading to complete system hangs. The vulnerability specifically affects systems using NVMe storage with the FEMU fuzzing framework as demonstrated by the syzkaller testing environment.
The fix implemented addresses this inconsistency by ensuring that sync_blockdev() is skipped during surprise removal conditions, matching the behavior of fs_bdev_mark_dead(). This maintains the proper conditional logic where only orderly removals (surprise == false) will proceed with the synchronization operations. The invalidate_bdev() function still executes as expected, ensuring proper device invalidation while avoiding the problematic sync operation that leads to system hangs. This approach aligns with established security practices for handling device removal scenarios and prevents denial of service conditions in storage subsystems.
This vulnerability maps directly to CWE-835 which addresses infinite loops or infinite recursion in software systems, specifically manifesting as an infinite wait condition during device removal operations. The behavior also relates to ATT&CK technique T1490 which covers energy drain through malicious use of system resources, as the hanging condition consumes system resources indefinitely. The issue represents a classic race condition problem where the timing of device removal and synchronization operations creates an irrecoverable deadlock state in the kernel's block device management subsystem, highlighting the importance of proper conditional handling in concurrent system operations.
The fix maintains backward compatibility for normal device operations while resolving the specific hang condition that occurs during unexpected device removals. This ensures that storage subsystems can properly handle error conditions without causing system-wide freezes, which is critical for enterprise and embedded systems where reliability and stability are paramount requirements. The solution demonstrates proper kernel programming practices by ensuring consistent behavior across different code paths that handle similar scenarios, preventing potential security implications from resource exhaustion attacks targeting the block device layer.