EUVD-2026-80571
GHSA-p3q9-qqp5-6666
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Network reach only via a malicious NVMe-oF target the host was configured to attach (AV:N/PR:H), a specific positive-status command failure is required (AC:H), and impact is availability-only DoS.
Primary rating from Vendor (Linux).
CVSS VectorVendor: Linux
Lifecycle Timeline
7DescriptionCVE.org
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.
AnalysisAI
Linux kernel NVMe zoned-block setup can be forced into an inconsistent state in which a zoned queue is committed with a zero zone size, causing a shift-out-of-bounds (ilog2(0)) and a kernel-side denial of service on the storage I/O path. The flaw affects Linux 6.9 and later kernels with NVMe ZNS support when a zoned namespace's device, firmware, or an attacker-controlled NVMe-oF target answers the Identify Namespace (I/O Command Set specific) or nvme_set_max_append() Identify Controller command with a POSITIVE NVMe status code rather than a negative errno; this requires a host administrator to have attached that device or target, giving an assessed vector of AV:N/AC:H/PR:H/UI:N with high availability impact only. …
Unlock full vulnerability intelligence
- Risk assessment & exploitation conditions
- Attack chain visualization
- Remediation with exact patch versions
- Threat intelligence from 22 sources
- Personal watchlist & email alerts
Free forever · No credit card required
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata
Vulnerability AssessmentAI
| Exploitation | Requires the host to attach an NVMe namespace whose device/firmware - or an attacker-controlled NVMe-oF target - returns a POSITIVE NVMe status code (not a negative errno) to either the Identify Namespace (I/O Command Set specific) command or the Identify Controller command issued by nvme_set_max_append(). … Additional conditions and limiting factors are described in the full assessment. |
| Risk Assessment | This is a denial-of-service integrity/availability bug in the Linux kernel NVMe zoned-block subsystem, not a memory-corruption RCE. … Full risk analysis with EPSS, KEV, and SSVC signal comparison available after sign-in. |
| Exploit Scenario | Full exploit scenario with step-by-step reproduction available after sign-in. |
| Remediation | Apply the upstream kernel fixes for this issue: update to Linux 6.18.52, 7.2.5, or 7.3-rc2, which incorporate the stable commits 3838e80fcfb32e62baffb63c6dc0a60153665a4d, 7fad53ae2052a2b4fc7ca567d6555bdb1176ba35, and bb6dafa79040357cf5043836e1db108c2af8b1e1 respectively (advisory reference: https://nvd.nist.gov/vuln/detail/CVE-2026-89971; EUVD-2026-80571). … Detailed patch versions, workarounds, and compensating controls in full report. |
Recommended ActionAI
Within 24 hours, inventory all Linux hosts running kernel 6.9 or later that have NVMe ZNS namespaces or NVMe-over-Fabric target attachments enabled, and confirm which of those kernels include the vendor fix for CVE-2026-89971; flag any host where non-trusted or third-party NVMe-oF targets can be attached by an administrator. …
Sign in for detailed remediation steps and compensating controls.
Threat intelligence, references, and detailed analysis are available after sign-in.
Same technique Denial Of Service
View allShare
External POC / Exploit Code
Leaving vuln.today