CVE-2026-89971: nvme: skip the zoned limits update if the zone info query failed
In the Linux kernel, the following vulnerability has been resolved:
nvme: skip the zoned limits update if the zone info query failed
nvmequeryzoneinfo() returns either a negative errno or a positive NVMe status code, but nvmeupdatensinfoblock() only tests for the negative case:
ret = nvmequeryzoneinfo(ns, lbaf, &zi); if (ret < 0) goto out;
If the device fails the Identify Namespace (I/O Command Set specific) command, or the Identify Controller command issued by nvmesetmaxappend(), the positive status falls through and setup continues with the zero-initialized zone info. nvmeupdatezoneinfo() then marks the queue zoned with chunksectors and ns->head->zsze set to zero.
blkvalidatezonedlimits() does not check chunksectors, so the limits commit succeeds. blkrevalidatediskzones() 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 diskzoneno() 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 diskzoneno include/linux/blkdev.h:747 [inline] biostraddleszones include/linux/blkdev.h:1058 [inline] blkzonewplughandlewrite block/blk-zoned.c:1423 [inline] blkzoneplugbio.cold+0x25/0x1c8 block/blk-zoned.c:1605 blkmqsubmitbio+0x18fb/0x2870 block/blk-mq.c:3196 submitbhwbc+0x575/0x740 fs/buffer.c:2824 blockwritefullfolio+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 nvmequeryzoneinfo() that return a positive status logs anything, so the failure would otherwise be silent.
zi.zonesize 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.
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
Use the nvme/blk-zoned validation behavior described: ensure Linux does not update zoned queue limits when nvme_query_zone_info() fails. On affected systems, apply the kernel fix so nvme_update_ns_info_block() skips the zoned limits update when the zone info query failed instead of continuing with zero-initialized zone info.
Event History
Frequently Asked Questions
Which systems are affected by this failure mode?
Systems using an NVMe namespace configured as zoned are affected when the driver updates namespace information and either the Identify Namespace I/O Command Set-specific query or the Identify Controller command used by nvme_set_max_append() fails with a positive NVMe status code.
What condition triggers the invalid zoned-queue state?
The failure must be reported as a positive NVMe status code rather than a negative errno. The prior handling lets setup continue with zero-initialized zone information, resulting in a zoned queue with a zero zone size.
How can I tell whether a system has encountered this issue?
Kernel logs may show "Invalid non power of two zone size (0)" followed by a UBSAN shift-out-of-bounds report in disk_zone_no(), with a negative shift exponent. The affected device may appear as an NVMe disk such as nvme0n1 in the log output.