CVE-2026-31523

What it actually does

This is a local Linux kernel race condition in the NVMe PCI driver. During an NVMe controller reset, a user who can change the number of polled queues at runtime may create a short timing window where a high-priority polling task attempts to poll a queue that the block layer has not yet remapped. The queue may already be operating as an interrupt-driven queue, which can result in duplicate I/O completions. The expected impact is availability loss, such as kernel instability, I/O disruption, hang, or panic; confidentiality and integrity impact are not expected from the published description.

Why it matters to the business

Systems using affected Linux kernels with NVMe storage may be vulnerable to local denial of service, potentially causing application outages, storage I/O interruption, host crashes, or forced reboots. Exploitation requires local low-privileged access and precise timing, and there is currently no known public exploit or CISA KEV listing, so urgency is lower than for remotely exploitable flaws, but shared compute hosts, developer workstations, and multi-user Linux servers should still prioritize remediation because a local user could disrupt availability.

How an attack unfolds

An attacker first obtains local access to a Linux system using an affected kernel and NVMe PCI storage. They then manipulate runtime NVMe polling configuration while causing or waiting for an NVMe controller reset. In parallel, they generate high-priority polled I/O so that a polling task races with the block layer queue-map update. If the timing is successful, the task may poll a queue that is no longer configured for polling, creating duplicate completion handling. This can destabilize the kernel storage path and may lead to I/O errors, kernel warnings, hangs, or a full system crash. The attack does not provide a direct path to data theft or privilege escalation based on the available information; the main outcome is denial of service.

How to fix it

Upgrade to a vendor-supported Linux kernel that includes the NVMe PCI fix for ensuring that only actual polled queues are polled during reset and queue remapping. Because exact fixed versions were not provided, use the kernel packages or advisories from the operating system vendor and verify that the fix for CVE-2026-31523, or the upstream change titled "nvme-pci: ensure we're polling a polled queue," is included. If immediate patching is not possible, reduce exposure by disabling or avoiding NVMe polling/high-priority polled I/O where operationally feasible, preventing untrusted users from changing runtime block/NVMe queue settings, restricting local shell access, and scheduling maintenance windows for systems where NVMe resets or polling reconfiguration may occur.

How to confirm the fix worked

Confirm the running kernel is a vendor build that contains the NVMe PCI race-condition fix, not merely that an updated package is installed but not yet booted. Validate with the OS package manager, kernel changelog, vendor advisory, or source/backport notes, and compare the running kernel from `uname -r` with the fixed package. Where source validation is used, confirm the kernel includes the change associated with "nvme-pci: ensure we're polling a polled queue." Avoid attempting destructive race-condition reproduction on production systems. After remediation, review kernel logs for recurring NVMe reset, I/O completion, block-layer, or kernel panic messages and verify that NVMe polling configuration cannot be modified by untrusted users.

Typical attack path

1. Gain local access to an affected Linux system with NVMe PCI storage.
2. Identify that NVMe polling or high-priority polled I/O is available on the host.
3. Change the runtime polled queue count or related NVMe polling configuration.
4. Trigger or wait for an NVMe controller reset while queue mappings are being updated.
5. Generate high-priority polled I/O during the reset window.
6. Win the race so polling occurs against a queue that has become interrupt-driven.
7. Cause duplicate I/O completions, resulting in storage disruption, kernel instability, hang, or crash.

How to detect it

There are no reliable exploit-specific indicators for this vulnerability; successful exploitation is likely to resemble a kernel or storage instability event. Review kernel logs, system journals, crash dumps, and audit records for sequences where NVMe polling or block queue settings changed shortly before NVMe controller resets, I/O errors, kernel warnings, hangs, or panics. Useful sources include `journalctl -k`, `/var/log/kern.log`, `/var/log/messages`, `dmesg`, kdump/vmcore data, auditd logs for writes to sysfs block/NVMe settings, and endpoint telemetry showing local users running I/O stress or storage configuration commands. Focus on suspicious correlation: local user activity, runtime polling configuration changes, NVMe reset messages, then abnormal termination or reboot. Absence of these artifacts does not prove non-exploitation because crashes may lose volatile logs and the race may not emit a unique message.

• nvme-pci
• nvme nvme
• resetting controller
• I/O error, dev nvme
• blk_update_request: I/O error
• Buffer I/O error on dev nvme
• BUG: kernel NULL pointer dereference
• kernel panic
• Oops:
• watchdog: BUG: soft lockup
• watchdog: BUG: hard LOCKUP
• /sys/block/*/queue/io_poll
• /sys/module/nvme_core/parameters/*
• /sys/module/nvme/parameters/*

What your security team should do

• Inventory Linux systems using NVMe PCI storage and identify those running affected or unverified kernel versions.
• Prioritize patching multi-user systems, shared compute environments, virtualization hosts, CI/build workers, and any Linux hosts where untrusted users can run local code.
• Apply the vendor kernel update containing the NVMe PCI polling-queue race fix and reboot into the fixed kernel.
• If patching is delayed, disable or avoid NVMe polling/high-priority polled I/O where possible and restrict permissions for runtime storage queue configuration changes.
• Monitor kernel logs for NVMe resets, block-layer I/O errors, kernel warnings, hangs, or panics that coincide with local user activity or polling configuration changes.
• Because EPSS is very low, exploit maturity is listed as none, and the issue is not in CISA KEV, treat this as an availability-hardening patch rather than an emergency internet-facing incident unless local untrusted users are present.