CVE-2026-80787 Overview
CVE-2026-80787 is a use-after-free vulnerability in the Linux kernel's NVMe target PCI endpoint function driver (nvmet_pci_epf). The flaw resides in nvmet_pci_epf_exec_iod_work(), which reads I/O descriptor fields after calling req->execute(). Because commands can complete asynchronously on another CPU, the I/O descriptor (iod) may be freed before those fields are read. KFENCE identified the issue as a use-after-free read on a kmalloc-1k allocation. The upstream fix reorders the accesses so iod->data_len and iod->dma_dir are read before command submission.
Critical Impact
Concurrent completion of NVMe target commands can free the I/O descriptor while another worker still reads its fields, leading to kernel memory corruption and potential denial of service on systems exposing NVMe targets over PCI endpoint function.
Affected Products
- Linux kernel nvmet_pci_epf driver (NVMe target PCI endpoint function)
- Stable kernel branches referenced by upstream commits 1ed1eea, 20be486d, c9e9bb75, and cede8d28
- Systems configured as NVMe-oF targets over PCI endpoint function
Discovery Timeline
- 2026-09-04 - CVE-2026-80787 published to NVD
- 2026-09-04 - Last updated in NVD database
Technical Details for CVE-2026-80787
Vulnerability Analysis
The function nvmet_pci_epf_exec_iod_work() submits an I/O command via req->execute() and then decides whether to wait for completion. That decision depends on iod->data_len and iod->dma_dir, both of which describe the transfer direction and size.
The problem is ordering. Once req->execute() returns, the command may already have completed on another CPU. For commands that do not transfer data from the device to the host, nvmet_pci_epf_queue_response() invokes nvmet_pci_epf_complete_iod() directly. That path frees the iod structure through nvmet_pci_epf_free_iod() before the submitting worker reads its fields. KFENCE flagged the resulting read as a use-after-free against a 712-byte allocation from kmalloc-1k.
The upstream fix caches iod->data_len and iod->dma_dir in local variables before calling req->execute(). The remaining accesses, such as iod->status, are only reached on the device-to-host read path, where nvmet_pci_epf_queue_response() signals iod->done instead of freeing the descriptor.
Root Cause
The root cause is a race condition combined with a use-after-free [CWE-416]. The submitting worker assumed exclusive ownership of the iod after calling req->execute(), but the completion path could reclaim the allocation immediately on a separate CPU before the worker finished inspecting descriptor fields.
Attack Vector
Triggering the flaw requires the target system to be configured as an NVMe-oF PCI endpoint function target and to receive I/O commands from a host. Any workload that issues non-data-in commands can race the completion path. Exploitation is limited to environments running the nvmet_pci_epf module, which is a narrow deployment surface. The primary observed impact is kernel memory corruption leading to instability or denial of service.
The vulnerability manifests as an ordering bug between two kernel workers. See the referenced kernel commits for the exact patch details.
Detection Methods for CVE-2026-80787
Indicators of Compromise
- KFENCE reports containing use-after-free read in nvmet_pci_epf_exec_iod_work in kernel logs.
- Kernel oops or panic traces referencing nvmet_pci_epf_exec_iod_work, nvmet_pci_epf_complete_iod, or nvmet_pci_epf_free_iod.
- Unexpected nvmet_pci_epf worker faults in dmesg under I/O load.
Detection Strategies
- Enable KFENCE (CONFIG_KFENCE=y) on test kernels running the nvmet_pci_epf driver to surface the race deterministically.
- Monitor for kernel version and loaded modules across fleet inventory to identify systems with nvmet_pci_epf present on unpatched kernels.
- Correlate NVMe target workload spikes with kernel warnings in centralized log pipelines.
Monitoring Recommendations
- Forward dmesg and /var/log/kern.log to a central log store and alert on KFENCE, KASAN, and use-after-free patterns.
- Track uname -r and lsmod | grep nvmet_pci_epf output across NVMe target hosts to validate patch coverage.
- Alert on unexpected reboots or kernel worker crashes on systems providing NVMe-oF PCI EPF targets.
How to Mitigate CVE-2026-80787
Immediate Actions Required
- Update to a Linux kernel release that includes the upstream fixes referenced by commits 1ed1eea, 20be486d, c9e9bb75, and cede8d28.
- Inventory systems loading the nvmet_pci_epf module and prioritize them for patching.
- On systems that do not require NVMe target PCI endpoint function support, unload and blacklist the module.
Patch Information
The fix reads iod->data_len and iod->dma_dir before calling req->execute(), eliminating the race with the asynchronous completion path. Refer to the upstream commits: Kernel Git Commit 1ed1eea, Kernel Git Commit 20be486d, Kernel Git Commit c9e9bb75, and Kernel Git Commit cede8d28.
Workarounds
- Unload the nvmet_pci_epf module (modprobe -r nvmet_pci_epf) on hosts that do not require NVMe target PCI EPF functionality.
- Blacklist the module in /etc/modprobe.d/ to prevent it from loading at boot on unpatched systems.
- Restrict which hosts can initiate I/O against the NVMe-oF target until patched kernels are deployed.
# Configuration example
# Prevent nvmet_pci_epf from loading on unpatched hosts
echo 'blacklist nvmet_pci_epf' | sudo tee /etc/modprobe.d/blacklist-nvmet-pci-epf.conf
sudo modprobe -r nvmet_pci_epf
sudo update-initramfs -u
# Verify kernel version after patching
uname -r
lsmod | grep nvmet_pci_epf
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.