CVE-2026-64326

What it actually does

This is a Linux kernel denial-of-service flaw in block-device removal handling. When a block device is surprise-removed, the kernel may incorrectly call sync_blockdev() even though the device is already gone. If writeback is pending and can no longer complete, the caller can block indefinitely in folio_wait_writeback(). In the observed path, an NVMe reset worker can become wedged after lost I/O queues, and other tasks waiting on that worker or related block-device operations can also hang. The impact is availability degradation or a system hang rather than code execution or data disclosure.

Why it matters to the business

Systems using affected Linux kernels may become unresponsive or experience stuck storage operations after unexpected block-device loss, NVMe controller resets, hot-unplug events, virtualization-backed disk failures, or similar storage disruptions. This can interrupt applications, delay recovery from storage faults, require manual reboot or node replacement, and increase downtime risk for servers, Kubernetes nodes, hypervisors, appliances, and storage-heavy workloads. EPSS is low and there is no known KEV listing or ransomware association, so urgency is highest for environments with removable, virtualized, or failure-prone block devices rather than broad internet-exposed risk.

How an attack unfolds

An attacker would need a way to trigger or induce surprise removal or reset behavior for a block device on an affected Linux system. This could occur through local access to device-management interfaces, control over a virtualized/emulated storage device, malicious or faulty hardware behavior, or a privileged path that can cause NVMe namespace or block-device teardown. During the surprise-removal path, the kernel marks the disk dead and incorrectly attempts to synchronize the bare block device. Because the device is already unavailable, pending writeback may never complete. The blocked synchronization can wedge the reset worker and cause dependent tasks to hang, resulting in denial of service.

How to fix it

Apply the Linux kernel update from the relevant distribution or kernel vendor that includes the fix to skip sync_blockdev() during surprise block-device removal in bdev_mark_dead(). If exact package fixed versions are not available from the advisory source, track the fix through vendor kernel errata, stable kernel release notes, or downstream distribution security updates. Prioritize updates on systems with NVMe devices, hot-pluggable storage, virtualized disks, storage appliances, hypervisors, CI/fuzzing infrastructure, and nodes where forced storage resets or detachments are operationally common. As temporary mitigations, restrict local privileged access to block-device management, limit untrusted control over virtual or emulated storage devices, avoid unnecessary hot-unplug workflows, and ensure watchdogs or cluster automation can recover wedged nodes. Mitigations do not fully eliminate the kernel bug; patching is the durable fix.

How to confirm the fix worked

Confirm the running kernel includes the vendor patch for the block-layer change that avoids sync_blockdev() on surprise removal in bdev_mark_dead(). Validate by checking the installed kernel package version against the distribution’s fixed advisory once published, then reboot into the fixed kernel and confirm with uname -a or package-manager inventory. In test environments only, reproduce a controlled surprise-removal or NVMe reset scenario and verify that reset workers and block-device operations do not hang indefinitely. Operationally, monitor for absence of recurring stuck-task warnings, hung nvme reset worker traces, and blocked folio_wait_writeback stacks after storage detach or reset events.

Typical attack path

1. Obtain local, privileged, physical, or virtualization-level ability to influence a Linux block device or NVMe device state.
2. Cause a surprise removal, lost I/O queue condition, namespace death, reset failure, or equivalent block-device teardown event.
3. Trigger the affected kernel path where bdev_mark_dead(..., surprise=true) is reached for a bare block device.
4. The kernel incorrectly calls sync_blockdev() despite the surprise-removal condition.
5. Pending writeback waits indefinitely because the removed device cannot complete I/O.
6. Storage reset or block-device worker threads become stuck, and tasks waiting on them hang, causing service disruption or requiring reboot.

How to detect it

Look for evidence of prior storage-triggered denial of service rather than payload execution. Relevant sources include kernel logs, system journal entries, dmesg output, crash dumps, kdump/vmcore analysis, hypervisor storage-event logs, cloud or virtualization disk-detach events, node watchdog records, and monitoring alerts for hung tasks or blocked I/O. Search for NVMe reset failures, lost I/O queues, disk or namespace death, surprise removal, hung task warnings, and blocked call stacks involving bdev_mark_dead(), sync_blockdev(), folio_wait_writeback(), blk_mark_disk_dead(), nvme_mark_namespaces_dead(), or nvme_reset_work(). Correlate these with sudden service unavailability, node NotReady events, storage path resets, or manual reboots. Because the issue is a kernel availability bug, there may be no attacker-specific artifact; repeated timing around administrative detach/reset operations or untrusted virtual device activity is more suspicious.

• I/O queues lost
• nvme_reset_work
• nvme_mark_namespaces_dead
• blk_mark_disk_dead
• bdev_mark_dead
• sync_blockdev
• folio_wait_writeback
• task blocked for more than
• blocked for more than 120 seconds
• INFO: task
• hung_task
• invalidate_bdev
• surprise removal
• marking disk dead
• namespace dead

What your security team should do

• Inventory Linux systems running kernels in the affected range once vendor advisories identify fixed package versions.
• Prioritize patching storage-dense systems, virtualization hosts, Kubernetes worker nodes, appliances, and servers with NVMe or hot-pluggable block devices.
• Schedule kernel updates and reboots through normal maintenance channels; live patching may not be available for this block-layer behavior change.
• Restrict access to privileged device-management capabilities, including block-device detach/reset operations and hypervisor controls for virtual disks.
• Review monitoring for hung tasks, blocked I/O, NVMe reset failures, and unexpected storage removal events.
• Ensure high-availability, fencing, watchdog, and node-replacement procedures can recover systems that become storage-wedged before patching.
• Do not treat this as an internet-facing remote-code-execution issue; focus response on availability, local privilege boundaries, and infrastructure resilience.