CVE-2026-43449

What it actually does

This flaw is a slab out-of-bounds read in the Linux kernel NVMe PCI driver, specifically in the doorbell buffer handling path used during NVMe controller reset and queue management. The vulnerable logic iterates beyond the valid range of online NVMe queues: online_queues is a count, so valid queue indexes end at online_queues - 1, while the buggy loop can access one entry past the allocated queue metadata. Because this occurs in kernel memory, a local attacker who can influence NVMe device state, trigger NVMe reset paths, or operate in an environment with controllable PCI/NVMe devices may be able to cause kernel memory disclosure or a kernel crash. The published CVSS vector indicates local attack, low complexity, low privileges, no user interaction, high confidentiality impact, and high availability impact.

Why it matters to the business

Successful exploitation could expose sensitive kernel memory or cause affected Linux systems using NVMe PCI storage to crash or become unstable. The most likely operational impact is denial of service on servers, workstations, appliances, or virtualized systems that use the vulnerable NVMe PCI driver path. Because this is not listed in CISA KEV, has no known exploit maturity, and has a very low EPSS score, broad active exploitation is not currently indicated; however, kernel memory-corruption issues should still be prioritized for systems where local users, containers, virtual machines, or untrusted hardware access are present.

How an attack unfolds

An attacker first needs local execution or another way to interact with a vulnerable Linux host where the nvme-pci driver is in use. They then attempt to trigger NVMe queue initialization, reset, teardown, or error-handling paths that call the vulnerable doorbell buffer setup/free logic. When the kernel processes the affected NVMe reset workflow, the off-by-one queue iteration can read outside the allocated slab object. In a basic exploitation scenario this results in a kernel oops, panic, or service outage. In a more advanced scenario, the out-of-bounds kernel read may expose adjacent kernel memory contents, although practical exploitation depends heavily on kernel build options, memory layout, hardening features, device accessibility, and the attacker’s ability to repeatedly shape NVMe driver state.

How to fix it

Upgrade to a Linux kernel version from the distribution or kernel vendor that includes the nvme-pci fix for the out-of-bounds access in nvme_dbbuf_set/nvme_dbbuf_free. No exact fixed package versions were provided in the input, so use the fixed kernel builds published by the relevant Linux distribution, appliance vendor, cloud image provider, or upstream stable kernel branch once available. After installing the fixed kernel, reboot the system so the patched kernel and nvme-pci module are active. Where immediate patching is not possible, reduce exposure by limiting local shell access, restricting untrusted workloads, preventing untrusted users from managing PCI/NVMe devices, avoiding passthrough of untrusted NVMe devices to guests, and disabling or avoiding affected NVMe PCI hardware paths only where operationally feasible. Kernel hardening features such as KASLR, slab hardening, module signing, lockdown mode, and panic-on-oops policy may reduce exploitability or improve containment but should not be treated as substitutes for patching.

How to confirm the fix worked

Confirm the running kernel is a vendor build that includes the nvme-pci bounds-check correction. Validate with the distribution advisory, package changelog, kernel commit reference, or source diff showing the loop condition was changed so queue indexes stay below dev->online_queues and skip only the admin queue at index 0. Check the running kernel with commands such as uname -r and package-manager queries, then ensure the host has rebooted into the patched kernel rather than merely installing it. On systems with NVMe PCI devices, verify normal device operation after reboot using tools such as dmesg, journalctl, lsblk, lspci, and nvme-cli. Exposure can be confirmed by identifying systems that load the nvme driver and have PCI NVMe controllers present; systems without the affected driver path are less exposed.

Typical attack path

1. Gain local code execution or equivalent low-privileged access on a Linux system using the NVMe PCI driver.
2. Confirm the system has NVMe PCI storage or an emulated/attached NVMe PCI controller handled by the vulnerable kernel driver.
3. Trigger NVMe controller reset, queue reinitialization, device removal/reprobe, power-state transition, or error-recovery behavior.
4. Cause the vulnerable nvme_dbbuf_set/nvme_dbbuf_free path to iterate beyond the valid online queue index range.
5. Observe a kernel crash, KASAN report, oops, panic, or potential kernel memory disclosure depending on system configuration and exploit reliability.

How to detect it

Look for evidence of kernel crashes or memory-safety reports involving the NVMe PCI driver. Primary log sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, /var/log/syslog, crash dumps, kdump/vmcore records, hypervisor console logs, and endpoint telemetry that captures kernel oops or panic events. Search for KASAN reports referencing slab-out-of-bounds in nvme_dbbuf_set or nvme_dbbuf_free, call traces involving nvme_reset_work and nvme-reset-wq, and repeated NVMe controller resets preceding a crash. Exploitation may leave no durable artifact beyond kernel logs, system instability, reboot records, or crash dumps. If crash dumps are available, inspect stack traces for drivers/nvme/host/pci.c around nvme_dbbuf_set, nvme_dbbuf_free, and nvme_reset_work. Because this issue is local and no public exploitation or named threat actor activity is indicated, detection should focus on anomalous local activity around NVMe reset paths and kernel fault artifacts rather than network indicators.

• BUG: KASAN: slab-out-of-bounds in nvme_dbbuf_free
• BUG: KASAN: slab-out-of-bounds in nvme_dbbuf_set
• nvme_dbbuf_set+
• nvme_dbbuf_free drivers/nvme/host/pci.c
• nvme_dbbuf_set drivers/nvme/host/pci.c
• nvme_reset_work+
• Workqueue: nvme-reset-wq nvme_reset_work
• Read of size 2 at addr
• The buggy address belongs to the object
• drivers/nvme/host/pci.c:377
• drivers/nvme/host/pci.c:404
• KASAN: slab-out-of-bounds
• kernel BUG at drivers/nvme/host/pci.c
• Oops:
• Kernel panic
• nvme-reset-wq

What your security team should do

• Inventory Linux systems using NVMe PCI storage or NVMe PCI passthrough and prioritize them for kernel updates.
• Patch and reboot affected systems using vendor-supported kernel packages that include the nvme-pci bounds-check fix.
• Prioritize multi-user systems, virtualization hosts, container hosts, developer workstations, CI runners, and systems where untrusted users or workloads have local execution.
• Review kernel logs for prior KASAN, oops, panic, or nvme-reset-wq events matching the vulnerable call path.
• Restrict local administrative capabilities related to PCI device binding, NVMe reset operations, hotplug, and hardware passthrough until patched.
• For virtualization platforms, avoid exposing untrusted or user-controlled NVMe PCI devices to guests unless the host kernel is patched.
• Monitor vendor advisories because exact fixed kernel package versions may differ across distributions and downstream products.
• Do not defer remediation solely because EPSS is low or the issue is not in CISA KEV; local kernel flaws can become more relevant when paired with sandbox escapes or initial footholds.