{"id":24658,"date":"2026-09-16T20:32:36","date_gmt":"2026-09-16T12:32:36","guid":{"rendered":"https:\/\/www.54iter.cn\/?vuln=cve-2026-89971"},"modified":"2026-09-16T20:32:36","modified_gmt":"2026-09-16T12:32:36","slug":"cve-2026-89971","status":"publish","type":"vuln","link":"https:\/\/www.54iter.cn\/?vuln=cve-2026-89971","title":{"rendered":"CVE-2026-89971 &#8211; In the Linux kernel, the following vulnerability has been resolved:\n\nnvme: skip the zoned"},"content":{"rendered":"<p>In the Linux kernel, the following vulnerability has been resolved:<\/p>\n<p>nvme: skip the zoned limits update if the zone info query failed<\/p>\n<p>nvme_query_zone_info() returns either a negative errno or a positive<br \/>\nNVMe status code, but nvme_update_ns_info_block() only tests for the<br \/>\nnegative case:<\/p>\n<p>\tret = nvme_query_zone_info(ns, lbaf, &amp;zi);<br \/>\n\tif (ret head-&gt;zsze set to<br \/>\nzero.<\/p>\n<p>blk_validate_zoned_limits() does not check chunk_sectors, so the limits<br \/>\ncommit succeeds.  blk_revalidate_disk_zones() does reject the zero zone<br \/>\nsize, but by then the limits are live and nothing rolls them back, so<br \/>\nI\/O keeps being submitted to a zoned queue with a zero zone size and<br \/>\ndisk_zone_no() shifts by ilog2(0):<\/p>\n<p>  nvme0n1: Invalid non power of two zone size (0)<br \/>\n  UBSAN: shift-out-of-bounds in include\/linux\/blkdev.h:747:16<br \/>\n  shift exponent -1 is negative<br \/>\n   disk_zone_no include\/linux\/blkdev.h:747 [inline]<br \/>\n   bio_straddles_zones include\/linux\/blkdev.h:1058 [inline]<br \/>\n   blk_zone_wplug_handle_write block\/blk-zoned.c:1423 [inline]<br \/>\n   blk_zone_plug_bio.cold+0x25\/0x1c8 block\/blk-zoned.c:1605<br \/>\n   blk_mq_submit_bio+0x18fb\/0x2870 block\/blk-mq.c:3196<br \/>\n   submit_bh_wbc+0x575\/0x740 fs\/buffer.c:2824<br \/>\n   __block_write_full_folio+0x728\/0xdd0 fs\/buffer.c:1933<\/p>\n<p>Any device, firmware or NVMe-oF target that fails this one command<br \/>\nreaches this.<\/p>\n<p>Skip the zoned limits update in that case, and log which of the two<br \/>\nthings happened: during a revalidation the queue keeps the zone<br \/>\ngeometry it was last validated with, and on a first scan the namespace<br \/>\nis registered without zoned limits, so that it is still available as a<br \/>\nhandle for admin commands.  Neither of the paths in<br \/>\nnvme_query_zone_info() that return a positive status logs anything, so<br \/>\nthe failure would otherwise be silent.<\/p>\n<p>zi.zone_size is an exact indicator: every path that returns a positive<br \/>\nstatus returns before it is assigned, and after that the only failure<br \/>\nleft is -ENODEV, which the caller already handles.<\/p>\n<p>Found by FuzzNvme.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>In the Linux kernel, the following vulnerability has been resolved:<\/p>\n<p>nvme: skip the zoned limits update if the zone info query failed<\/p>\n<p>nvme_query_zone_info() returns either a negative errno or a posit<\/p>\n","protected":false},"template":"","meta":[],"categories":[],"tags":[],"class_list":["post-24658","vuln","type-vuln","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln\/24658","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln"}],"about":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/types\/vuln"}],"wp:attachment":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=24658"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=24658"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=24658"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}