CVE-2026-89971
largeLinux kernel NVMe zoned-namespace DoS from mishandled zone-info query failure
The Linux kernel NVMe driver mishandles failures of the zone-information query: nvme_query_zone_info() can return a positive NVMe status code, but nvme_update_ns_info_block() only checks for negative errno values, so a failed command is treated as success and the namespace's zone size is committed as zero. Once the zoned queue is live with a zero zone size, writes trigger a shift-out-of-bounds in disk_zone_no() (ilog2(0)) in the block zoned-write-plug path, producing 'Invalid non power of two zone size' errors and kernel instability on the device. Any zoned NVMe device, drive firmware, or NVMe-oF target that fails this single command can trigger the condition, including a remote NVMe-oF target returning a failure during namespace scan or revalidation, yielding denial of service on the host (CVSS 7.5, network vector, high availability impact). Affected are Linux systems using zoned NVMe namespaces (ZNS SSDs or NVMe-oF zoned targets); the fix makes a first-scan failure register the namespace without zoned limits (still usable for admin commands) and keeps the last-validated geometry during revalidation. No exploitation is known; the bug was found by the FuzzNvme fuzzer and is not listed in CISA KEV.
What to do: Update to a kernel that includes the fix 'nvme: skip the zoned limits update if the zone info query failed' via your distribution's kernel channel (fixed version numbers were not stated in the source data). Until patched, restrict NVMe-oF hosts to trusted targets only, since a remote target can trigger the failure, and monitor logs for 'Invalid non power of two zone size' or UBSAN shift-out-of-bounds reports in blk-zoned code as indicators of a triggering device, firmware, or target. Investigate and repair the offending device/firmware or disconnect the failing NVMe-oF target to restore service.
| Linux kernel (NVMe driver / zoned namespace support, nvme_update_ns_info_block) | Kernels containing the vulnerable zoned-limits error handling in nvme_update_ns_info_block(); no fixed version numbers provided in the source data (fix commit: |
Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.
In the Linux kernel, the following vulnerability has been resolved: nvme: skip the zoned limits update if the zone info query failed nvme_query_zone_info() returns either a negative errno or a positive NVMe status code, but nvme_update_ns_info_block() only tests for the negative case: ret = nvme_query_zone_info(ns, lbaf, &zi); if (ret head->zsze set to zero. blk_validate_zoned_limits() does not check chunk_sectors, so the limits commit succeeds. blk_revalidate_disk_zones() does reject the zero zone size, but by then the limits are live and nothing rolls them back, so I/O keeps being submitted to a zoned queue with a zero zone size and disk_zone_no() shifts by ilog2(0): nvme0n1: Invalid non power of two zone size (0) UBSAN: shift-out-of-bounds in include/linux/blkdev.h:747:16 shift exponent -1 is negative disk_zone_no include/linux/blkdev.h:747 [inline] bio_straddles_zones include/linux/blkdev.h:1058 [inline] blk_zone_wplug_handle_write block/blk-zoned.c:1423 [inline] blk_zone_plug_bio.cold+0x25/0x1c8 block/blk-zoned.c:1605 blk_mq_submit_bio+0x18fb/0x2870 block/blk-mq.c:3196 submit_bh_wbc+0x575/0x740 fs/buffer.c:2824 __block_write_full_folio+0x728/0xdd0 fs/buffer.c:1933 Any device, firmware or NVMe-oF target that fails this one command reaches this. Skip the zoned limits update in that case, and log which of the two things happened: during a revalidation the queue keeps the zone geometry it was last validated with, and on a first scan the namespace is registered without zoned limits, so that it is still available as a handle for admin commands. Neither of the paths in nvme_query_zone_info() that return a positive status logs anything, so the failure would otherwise be silent. zi.zone_size is an exact indicator: every path that returns a positive status returns before it is assigned, and after that the only failure left is -ENODEV, which the caller already handles. Found by FuzzNvme.
- Vector
- CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
In the news0 stories
No ingested article mentions this CVE yet.