Cloudanix VulnDB

CVE-2026-80821

None

CVSS

—

EPSS

0.2%

Published

Sep 4, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in the Linux kernel's NVMe target code can let a connected device slowly consume memory by sending certain commands that are never properly cleaned up.

Exploitation
Remote Unauthenticated
Attacker needs
None
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Memory Corruption
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Missing nvmet_cq_put() on PCI mapping failure paths after successful nvmet_cq_create() in nvmet_pci_epf_create_cq() leaks a CQ object and controller reference on each Create IO CQ command that supplies a failing PRP1 address.

Why it matters to the business

Remote PCI endpoint hosts can trigger unbounded reference-count growth, eventually exhausting kernel memory and disrupting NVMe target availability in affected Linux kernels.

How an attack unfolds

An attacker controlling a PCI host issues repeated Create IO CQ commands whose PRP1 mapping fails or returns a partial mapping; the error paths skip the put, the LIVE flag is never set, and nvmet_pci_epf_delete_cq() therefore never releases the leaked references, allowing steady accumulation until the system is impaired.

How to fix it

Apply the upstream fix that adds nvmet_cq_put() calls on the err_internal and err_unmap_queue paths; rebuild and deploy the corrected kernel image to all affected systems.

How to confirm the fix worked

Confirm the presence of the paired put operations after nvmet_cq_create() in nvmet_pci_epf.c and verify that the NVMET_PCI_EPF_Q_LIVE flag is only set after a successful full mapping.

Typical attack path

  1. Establish PCI link to the vulnerable nvmet-pci-epf endpoint
  2. Issue NVM Express Create IO CQ commands with deliberately invalid or unmappable PRP1 values
  3. Observe successful CQ object creation followed by mapping failure
  4. Repeat to accumulate leaked references without triggering normal teardown

How to detect it

Inspect kernel logs for repeated mapping-failure messages around nvmet_pci_epf_create_cq, watch for steadily rising CQ or controller reference counts via debugfs or slabinfo, and correlate with PCI endpoint activity from untrusted hosts.

What your security team should do

  • Prioritize kernel updates containing the reference-put correction within the next maintenance window
  • Review any custom nvmet-pci-epf configurations for exposure to untrusted PCI hosts
  • Monitor memory usage and reference-count statistics on systems exposing this interface

The record

In the Linux kernel, the following vulnerability has been resolved: nvmet: pci-epf: put CQ ref on create_cq mapping failure nvmet_pci_epf_create_cq() calls nvmet_cq_create(), which takes a reference on the controller and installs the completion queue. If the subsequent PCI address-space mapping fails or returns a too-small partial mapping, the function jumps to err_internal / err_unmap_queue without calling nvmet_cq_put(). The matching put in nvmet_pci_epf_delete_cq() is gated on NVMET_PCI_EPF_Q_LIVE, which is only set after the mapping succeeds, so teardown never releases these references. A remote PCI host that drives Create IO CQ commands with a failing PRP1/pci_addr therefore leaks the CQ and a controller reference on each attempt. Drop the CQ reference on the mapping-failure paths. The err_internal and err_unmap_queue labels are only reachable after nvmet_cq_create() has succeeded, so this pairs the create/put correctly.

Affected packages

Ecosystem Package Introduced Fixed