Skip to main content
VulnerabilityPublished Updated

CVE-2026-80787: Linux kernel · nvmet: pci-epf: fix use-after-free in nvmet_pci_epf_exec_iod_work()

Affects Linux kernelSource GCVE Database

0

Not known to be exploited.

Data as of 26 Oct 2026, 17:16 UTC

Severity
Medium

Rated by Threat Radar · CVSS not yet scored by NVD

EPSS
0.2% chance of exploitation in 30 days – higher than 10% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 4 Sep 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponised: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.

What to do

Affected software

ProductAffectedFixed in
Ubuntu 26.04 LTSlinuxpkg:deb/ubuntu/linux?arch=source&distro=resoluteOther threatsAffected
  • 6.17.0-5.5 – 7.0.0-34.34
22 affected builds
Fixed in–
Ubuntu 26.04 LTSlinux-awspkg:deb/ubuntu/linux-aws?arch=source&distro=resoluteOther threatsAffected
  • 6.17.0-1002.2 – 7.0.0-1013.13
14 affected builds
Fixed in–
Ubuntu 26.04 LTSlinux-azurepkg:deb/ubuntu/linux-azure?arch=source&distro=resoluteOther threatsAffected
  • 6.17.0-1003.3 – 7.0.0-1014.14
14 affected builds
Fixed in–
Ubuntu 26.04 LTSlinux-azure-fdepkg:deb/ubuntu/linux-azure-fde?arch=source&distro=resoluteOther threatsAffected
  • 7.0.0-1003.3 – 7.0.0-1013.13
8 affected builds
Fixed in–
Ubuntu 26.04 LTSlinux-gcppkg:deb/ubuntu/linux-gcp?arch=source&distro=resoluteOther threatsAffected
  • 6.17.0-1002.2 – 7.0.0-1013.13
12 affected builds
Fixed in–
Ubuntu 26.04 LTSlinux-gkepkg:deb/ubuntu/linux-gke?arch=source&distro=resoluteOther threatsAffected
  • 7.0.0-1002.3 – 7.0.0-1007.8
5 affected builds
Fixed in–

Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.

AI-suggested

A fix for this vulnerability has been implemented in the Linux kernel by reordering the access to iod fields before the command execution call. Users should update their Linux kernel to a version that includes this fix. Since this is a kernel-level issue, applying the official kernel update is the recommended remediation. Patch status is not explicitly confirmed in the provided data; check the vendor or Linux kernel advisory for the exact fixed version and update accordingly.

Description

In the Linux kernel, the following vulnerability has been resolved: nvmet: pci-epf: fix use-after-free in nvmet_pci_epf_exec_iod_work() nvmet_pci_epf_exec_iod_work() submits an I/O command with req->execute() and then waits for the command to complete and transfers the data back to the host. This wait is not needed for commands that do not transfer data from the device to the host. To decide whether that wait is needed, it reads iod->data_len and iod->dma_dir after calling req->execute(). However, once req->execute() is called, the command may complete asynchronously on another CPU. For commands that do not require a device-to-host data transfer, nvmet_pci_epf_queue_response() calls nvmet_pci_epf_complete_iod() directly, which can free the iod before it reads iod->data_len and iod->dma_dir, resulting in the KFENCE use-after- free: BUG: KFENCE: use-after-free read in nvmet_pci_epf_exec_iod_work+0x288/0x798 [nvmet_pci_epf] Use-after-free read at 0x00000000fdfa6d03 (in kfence-#63): nvmet_pci_epf_exec_iod_work+0x288/0x798 [nvmet_pci_epf] process_one_work+0x15c/0x4f0 worker_thread+0x18c/0x30c kthread+0x130/0x140 ret_from_fork+0x10/0x20 kfence-#63: 0x00000000e3de0e71-0x00000000c938ad62, size=712, cache=kmalloc-1k allocated by task 10 on cpu 0 at 73.995480s (0.005122s ago): mempool_kmalloc+0x1c/0x28 mempool_alloc_noprof+0x40/0x9c nvmet_pci_epf_poll_sqs_work+0xd4/0x344 [nvmet_pci_epf] process_one_work+0x15c/0x4f0 worker_thread+0x18c/0x30c kthread+0x130/0x140 ret_from_fork+0x10/0x20 freed by task 131 on cpu 3 at 73.995521s (0.008385s ago): mempool_kfree+0x10/0x20 mempool_free+0x44/0x64 nvmet_pci_epf_free_iod+0x88/0x98 [nvmet_pci_epf] nvmet_pci_epf_cq_work+0xfc/0x280 [nvmet_pci_epf] process_one_work+0x15c/0x4f0 worker_thread+0x18c/0x30c kthread+0x130/0x140 ret_from_fork+0x10/0x20 Fix this by referring to iod->data_len and iod->dma_dir before calling req->execute(). The remaining iod accesses such as iod->status are only reached on the device-to-host read path. In this case, nvmet_pci_epf_queue_response() signals iod->done instead of freeing the iod, so the iod stays valid.

References

Community reviews

Loading reviews…