CVE-2026-80821: nvmet: pci-epf: put CQ ref on create_cq mapping failure
In the Linux kernel, the following vulnerability has been resolved:
nvmet: pci-epf: put CQ ref on createcq mapping failure
nvmetpciepfcreatecq() calls nvmetcqcreate(), 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 errinternal / errunmapqueue without calling nvmetcqput(). The matching put in nvmetpciepfdeletecq() is gated on NVMETPCIEPFQLIVE, 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/pciaddr therefore leaks the CQ and a controller reference on each attempt.
Drop the CQ reference on the mapping-failure paths. The errinternal and errunmapqueue labels are only reachable after nvmetcqcreate() has succeeded, so this pairs the create/put correctly.
Affected Software
Event History
Frequently Asked Questions
Who can trigger the resource leak?
A remote PCI host that can issue Create IO CQ commands to the nvmet PCI endpoint function can trigger it by supplying a PRP1/PCI address that causes address-space mapping to fail or return a partial mapping.
What is the impact of repeated failed requests?
Each affected Create IO CQ attempt leaks a completion queue and a controller reference. Repeated attempts can accumulate unreleased resources during the controller lifetime.
How can an administrator recognize exposure from behavior?
Exposure requires use of the nvmet PCI endpoint-function path and failed or too-small PCI address-space mappings while processing Create IO CQ commands. The described symptom is completion-queue and controller-reference growth following such failed requests.