CVE-2026-64326

UnknownEPSS 0.20%

Last modified

CVE-2026-64326 is a vulnerability of currently unknown severity. 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).. EPSS estimates a 0.20% chance of exploitation in the next 30 days.

Description

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).

Metrics

EPSS Probability
0.20%

10.1th percentile

Probability of exploitation in the next 30 days. Learn more

Affected Software

Source: CNA advisory (CVE.org). NVD analysis pending.

VendorProductVersions
LinuxLinux>= d8530de5a6e82be0ce17a5fdf727a394bcf6444c, < d6998ddd507c81e3829489a6ead23f17f5acb7fe; >= d8530de5a6e82be0ce17a5fdf727a394bcf6444c, < f41cf35ee2a1e31374b3f54e7579c55153506e70; >= d8530de5a6e82be0ce17a5fdf727a394bcf6444c, < 9818bcae3c0ca1dde4b9a334125c46676e0a9b29; >= d8530de5a6e82be0ce17a5fdf727a394bcf6444c, < aa4c4a9315764b2b7a7182e72cc5ea87520436b4; >= d8530de5a6e82be0ce17a5fdf727a394bcf6444c, < 49f06cff50a4ccf3b7a1a662ceb892b3b21a527a
LinuxLinux6.6

References

Timeline

Published
Last Modified
Status
Awaiting Analysis

Frequently Asked Questions

What is CVE-2026-64326?
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).
How severe is CVE-2026-64326?
Severity scoring for CVE-2026-64326 is pending analysis. The EPSS model estimates a 0.20% probability of exploitation in the next 30 days.
How do I fix CVE-2026-64326?
Check the vendor references and advisories linked above for patched versions and mitigation guidance. You can also run a Strix scan to test if your systems are affected.

How Strix Helps

Related CVEs from 2026

Are you affected by CVE-2026-64326?

Run a free Strix scan to check your systems for this vulnerability.

Scan your code now

Source: NVD / NIST