CVE-2026-89971 nvme: skip the zoned limits update if the zone info query failed

High 7.5 Published Updated

A logic error in the Linux kernel NVMe driver causes a shift-out-of-bounds crash when zone info queries fail, leading to denial of service.

Exploited in the wild
Not known
Login needed
Not needed
Attackable
Over the internet
Victim action needed
Not needed
Fix
Available

What is CVE-2026-89971?

CVE-2026-89971 is a high-severity vulnerability in Linux, published on 16 Sep 2026. An attacker can exploit it over the internet without logging in, with no action from the victim.

Official description

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 < 0) goto out;

If the device fails the Identify Namespace (I/O Command Set specific) command, or the Identify Controller command issued by nvme_set_max_append(), the positive status falls through and setup continues with the zero-initialized zone info. nvme_update_zone_info() then marks the queue zoned with chunk_sectors and ns->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.

Which versions are affected by CVE-2026-89971?

How do I fix CVE-2026-89971?

Apply the vendor's patch.

Is CVE-2026-89971 being exploited?

There is no known exploitation of CVE-2026-89971 in the wild and no public exploit code.

Sources

Also known as BELL-CVE-2026-89971, DEBIAN-CVE-2026-89971, GHSA-p3q9-qqp5-6666, UBUNTU-CVE-2026-89971.

Is CVE-2026-89971 in your software?

Upload an SBOM and sbomify checks it against every vulnerability here, every day.

Check your SBOMs for free