HowToFixMe
● Local out-of-bounds read

How to Fix CVE-2026-43449: nvme-pci slab-out-of-bounds in the Linux kernel

By the Sai Kiran Pandrala · Reviewed and edited by Sai Kiran Pandrala, Editor

Last verified: 2026-05-25

CVE-2026-43449 is an out-of-bounds read in the Linux kernel's NVMe over PCIe driver. The bug lives in nvme_dbbuf_set() in drivers/nvme/host/pci.c, where a loop walked one entry past the end of the per-queue doorbell-buffer array during a controller reset. KASAN caught it as a slab-out-of-bounds read. The fix is already in the stable kernels — upgrade your distro's kernel package to a build at or above the fixed version for your series and reboot. There is no userspace patch and no firewall workaround; this is kernel code.

⚡ At a glance
ProductLinux kernel — NVMe PCI driver (drivers/nvme/host/pci.c)
SeverityNo CVSS in record. Local out-of-bounds read; availability / possible info disclosure
Actively exploited?No — not on CISA KEV; no exploitation indicator in the record
AffectedMainline from 5.9.12 / 5.4.81 / 4.19.161 / 4.14.210 onward; stable series 5.10, 5.15, 6.1, 6.6, 6.12, 6.18, 6.19 before their fixed point release
Fixed in5.10.253, 5.15.203, 6.1.167, 6.6.130, 6.12.78, 6.18.19, 6.19.9, mainline 7.0
Type (CWE)Out-of-bounds read (CWE-125 class). No CWE assigned in the kernel record
Attacker requirementLocal; triggered on the NVMe controller reset path. No network exposure

Exploitation status

There is no CISA KEV entry for CVE-2026-43449 at present, so active in-the-wild exploitation has not been officially confirmed for this CVE. Do not wait for a KEV entry to act, since the catalog commonly lags real attacks, so patch on the usual severity-based schedule.

Public exploit availability: the primary references list no public exploit or Metasploit module as of writing. Private or unpublished exploit code may still exist, so do not downgrade the risk on that basis alone.

What is CVE-2026-43449?

This is a slab-out-of-bounds read in the kernel's NVMe-over-PCIe host driver. The affected function is nvme_dbbuf_set() (and the helper nvme_dbbuf_free() it calls) in drivers/nvme/host/pci.c. NVMe controllers can use a "shadow doorbell" buffer feature, where the kernel keeps a small per-queue array that mirrors the controller's doorbell registers. When the driver sets up or tears down those buffers, it iterates over the device's submission and completion queues.

The defect is a classic off-by-one. The field dev->online_queues is a count that gets incremented in nvme_init_queue(), so the valid array indices run from 0 through dev->online_queues - 1. The buggy loop condition let the index reach dev->online_queues itself, one slot past the end of the allocation. The fix tightens the loop so the index stays inside the valid range. Index 0 is also excluded, because slot 0 is the admin queue rather than an I/O queue.

The KASAN report in the kernel record makes the mechanism concrete. During nvme_reset_work (the controller reset path that runs on the nvme-reset-wq workqueue), nvme_dbbuf_set() called into nvme_dbbuf_free() and read 2 bytes 244 bytes past the end of a 1152-byte region carved out of the kmalloc-2k slab cache. KASAN flagged it as a read of size 2 at an out-of-bounds address.

Two things matter for how worried you should be. First, the trigger is the controller reset path — it fires during probe, resume, or a reset, not on attacker-supplied network input. Second, this is a read, not a write: the kernel reads memory it should not, which can crash the box (KASAN/panic builds), leak a small amount of adjacent slab content, or simply read garbage that gets used as a doorbell value. The attack surface is local and tied to NVMe hardware behaviour. The kernel CNA assigned no CVSS score and no CWE in this record; by mechanism it sits in the CWE-125 (out-of-bounds read) family with a local attack vector.

Why this CVE matters

Every modern Linux server with an NVMe SSD loads this driver. That is most cloud instances, most bare-metal database hosts, and a lot of laptops. The shadow-doorbell feature is common in virtualized NVMe and on real controllers that advertise it, so the vulnerable code path is genuinely reachable in everyday operation, not some exotic corner.

The practical impact is availability first. On a kernel built with KASAN or panic-on-oops, an out-of-bounds read in the reset path can take the machine down at exactly the wrong moment — during boot, during resume from suspend, or when the controller resets under load. On a normal production kernel the read may pass silently most of the time, but reading uninitialised or adjacent slab memory and feeding it back as a doorbell offset is the kind of latent corruption that produces hard-to-debug instability. There is also a small information-disclosure angle: the bytes read sit next to other kmalloc-2k allocations.

What this CVE is not: it is not remote code execution, it is not network-exploitable, and it is not something a firewall, WAF, or reverse proxy can touch. Anyone telling you to mitigate an NVMe driver bug with an iptables rule has misread the advisory. The only real fix is a patched kernel.

Am I affected?

You are affected if you run a Linux kernel built before the fixed point release for your stable series and you have NVMe storage. The bug predates the named stable backports — the kernel record lists it as present from the 4.14.210 / 4.19.161 / 5.4.81 / 5.9.12 backport points onward across the long-term branches, so this reaches back a long way.

Check the running kernel and your kernel package version:

# Which kernel is actually running right now
uname -r

# Which kernel packages are installed (Debian / Ubuntu)
dpkg -l 'linux-image-*' | grep ^ii

# RHEL / Rocky / Alma / Fedora
rpm -q kernel kernel-core

# openSUSE / SUSE
rpm -q kernel-default

Compare what you see against the fixed versions. You are safe at or above: 5.10.253 (5.10.x), 5.15.203 (5.15.x), 6.1.167 (6.1.x), 6.6.130 (6.6.x), 6.12.78 (6.12.x), 6.18.19 (6.18.x), 6.19.9 (6.19.x), or mainline 7.0. Distro kernels carry their own version strings (for example Ubuntu's 6.8.0-xx or RHEL's 5.14.0-xxx.el9), so the authoritative check is your distro's security tracker for this CVE rather than the raw upstream number — but the upstream fixed points tell you which backport you need.

How to fix CVE-2026-43449

Upgrade the kernel package through your distribution, then reboot onto the new kernel. There is nothing to rebuild, no service to reconfigure, and no userspace component — the fix is in the kernel binary itself. Do not try to build a single driver module out-of-tree unless you really know what you are doing; take the vendor kernel.

Ubuntu / Debian

sudo apt-get update
sudo apt-get install --only-upgrade linux-image-generic linux-headers-generic
# or update everything and let the meta-package pull the new kernel:
# sudo apt-get full-upgrade
sudo reboot

RHEL / CentOS Stream / Rocky / AlmaLinux / Fedora

sudo dnf upgrade --refresh kernel kernel-core
sudo reboot

openSUSE / SUSE

sudo zypper refresh
sudo zypper update kernel-default
sudo reboot

Arch Linux

sudo pacman -Syu linux
sudo reboot

After the reboot, confirm you are running the new kernel with uname -r. The reboot is not optional: a freshly installed kernel package does nothing until the machine boots into it. If your fleet uses live patching (kpatch, kGraft, Ubuntu Livepatch), check whether your vendor shipped this fix as a live patch; if not, a normal reboot is required.

If you can't patch immediately

There is no clean userspace mitigation, because the trigger is the kernel's own NVMe reset path rather than any input you control. Be honest about that. What you can do is reduce how often the vulnerable path runs and limit who can poke at it:

Skip the firewall and WAF rules entirely for this one. They are meaningless against a kernel driver bug and would give a false sense of safety.

How to verify the fix worked

Verification here is a version check plus a clean-boot check, not a network scan.

# 1. Confirm the running kernel is at or above the fixed point for your series
uname -r

# 2. Confirm the installed package matches (Debian / Ubuntu)
dpkg -l 'linux-image-*' | grep ^ii

# RHEL family
rpm -q kernel-core

# 3. Confirm no NVMe / KASAN out-of-bounds splat after boot
sudo dmesg | grep -iE 'nvme|kasan|out-of-bounds'

If uname -r shows a build at or above the fixed version for your series and dmesg is clean of NVMe slab-out-of-bounds reports after a fresh boot, you are running the patched code. For distro kernels, cross-check the version string against your distribution's advisory for CVE-2026-43449 to confirm the backport is included. Because this is not a remotely reachable flaw, there is no exposure window to forensically review and no credentials to rotate — the relevant evidence is the kernel version, not access logs.

Frequently asked questions

Is CVE-2026-43449 being exploited in the wild?

No. It is not on CISA's KEV catalog and the kernel record carries no exploitation indicator. The bug is a local out-of-bounds read in the NVMe controller reset path, not a remotely reachable flaw, so treat it as a normal-cadence stable-kernel upgrade.

What is the CVSS score for CVE-2026-43449?

The Linux kernel CNA did not assign a CVSS base score or a CWE in the published record. By mechanism it is a local out-of-bounds read (CWE-125 class) affecting availability and possibly leaking a small amount of adjacent kernel memory. Check the NVD entry if an analyst score is added later.

Which kernel versions fix CVE-2026-43449?

The fix shipped in stable kernels 5.10.253, 5.15.203, 6.1.167, 6.6.130, 6.12.78, 6.18.19, 6.19.9, and mainline 7.0. Upgrade your distro kernel package to a build at or above the fixed point for your series, then reboot. Distro kernels carry their own version strings, so confirm against your distribution's advisory.

Will a firewall rule or WAF help against CVE-2026-43449?

No. This is a kernel driver bug in the NVMe reset path, not a network service, so firewall and WAF rules do nothing here. Upgrading the kernel and rebooting is the only fix. There is no internet-facing exposure window to review and no service credentials to rotate.

Nearby vulnerabilities you may as well remediate alongside this fix:

References

Assembled from the upstream Linux kernel CVE record and stable-tree commit references on 2026-05-25. This CVE is not in the CISA KEV catalog. Always confirm the fixed version against your distribution's advisory before applying changes in production.