CVE-2026-98727 in Linux
Summary
by MITRE • 10/18/2026
In the Linux kernel, the following vulnerability has been resolved:
nvme-multipath: set BLK_FEAT_ZONED only after the zone info is known
The namespace head is marked zoned at allocation time based only on the command set identifier. If the zone info query reports a zero zone size, the path namespace is registered without zoned limits while the head still advertises the zoned capability with a zone size of zero, and reporting zones or writing to the head then shifts by ilog2(0).
Drop the zoned feature from the head allocation and let the head limits refresh stack it in from the path namespace instead.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/18/2026
The Linux kernel's NVMe driver contains a logic flaw within its multipath implementation that leads to undefined behavior during device initialization, specifically when handling zoned namespaces. The vulnerability stems from an incorrect sequence of operations where the namespace head is marked as zoned based solely on the command set identifier at allocation time, rather than waiting for definitive zone information from the underlying hardware. This premature flagging creates a state inconsistency between the logical representation of the device and its actual physical capabilities reported by the storage controller.
When the system queries the path namespace for detailed zone information, it may receive a response indicating a zero zone size, which typically signifies that the device does not support zoned operations or has not yet been fully configured. In this scenario, the path namespace is correctly registered without zoned limits because the hardware explicitly indicates no zoning capability. However, due to the earlier premature assignment of the zoned feature flag during head allocation, the namespace head continues to advertise itself as a zoned device with a zone size of zero. This discrepancy between the advertised capabilities and the actual operational parameters creates a critical mismatch in the block layer's understanding of the storage geometry.
The operational impact of this vulnerability manifests when user-space applications or kernel subsystems attempt to interact with the namespace head by reporting zones or issuing write commands that respect zoned constraints. Because the system believes it is dealing with a zoned device but perceives the zone size as zero, subsequent calculations involving logarithmic shifts are triggered on invalid data. Specifically, the code performs an ilog2 operation on the value zero to determine shift amounts for address translation or block alignment. Since the binary logarithm of zero is undefined and mathematically problematic in fixed-width integer arithmetic, this results in a shift by an incorrect amount, potentially leading to memory corruption, kernel panics, or data integrity issues depending on how the resulting invalid addresses are utilized within the storage stack.
This flaw represents a classic case of improper initialization order where state assumptions outpace actual hardware validation. It aligns with CWE-362, Concurrent Execution using Shared Resource with Improper Synchronization of Accesses, as it involves race-like conditions in state management during device probing and registration phases. Furthermore, the potential for kernel instability due to invalid arithmetic operations can be categorized under CWE-190, Integer Overflow or Wraparound, specifically regarding the misuse of logarithmic functions on edge-case inputs that violate mathematical domain constraints within low-level system code.
To mitigate this vulnerability, developers must ensure that feature flags such as BLK_FEAT_ZONED are not set during initial allocation based merely on command set identifiers. Instead, the zoned capability should be dynamically determined and applied only after the zone information has been successfully queried from the path namespace. By deferring the setting of the zoned feature until the head limits can be refreshed with accurate data from the underlying paths, the system ensures that the advertised capabilities always match the actual hardware configuration. This approach prevents the scenario where a device is treated as zoned while simultaneously reporting a zero zone size, thereby eliminating the risk of undefined behavior during subsequent I/O operations and ensuring robust handling of both zoned and non-zoned NVMe namespaces.