CVE-2026-98727

What it actually does

Incorrect early marking of BLK_FEAT_ZONED on namespace head based solely on command set identifier allows registration with zero zone size; subsequent zone report or write operations perform ilog2(0) shift, producing invalid arithmetic results or undefined behavior.

Why it matters to the business

Storage subsystem instability or kernel-level failures in NVMe multipath deployments using zoned namespaces can interrupt I/O, cause data path outages, and require emergency reboots or device recovery.

How an attack unfolds

An attacker supplies or emulates an NVMe device whose zone information query returns a zero zone size after head allocation; zone operations on the head then execute the erroneous shift, triggering crashes or incorrect device behavior.

How to fix it

Upgrade the Linux kernel to a version containing the nvme-multipath fix that defers BLK_FEAT_ZONED until after valid zone information is obtained from the path namespace.

How to confirm the fix worked

Confirm zone size reported by the head namespace is non-zero before any zoned I/O; inspect kernel source for the updated allocation and refresh logic; test with zoned NVMe hardware or emulators.

Typical attack path

1. Attach or present a zoned NVMe namespace whose zone query returns zero size
2. Trigger zone report ioctl or zoned write on the multipath head
3. Observe resulting arithmetic fault or kernel panic

How to detect it

Search kernel logs and dmesg for nvme, zoned, or multipath errors mentioning zone size zero or shift-by-zero faults; examine device initialization traces around namespace registration.

What your security team should do

• Prioritize kernel updates for systems exposing NVMe multipath zoned devices
• Monitor storage-related kernel logs for ilog2 or zone-size anomalies
• Isolate or disable multipath zoned namespaces until patched