CVE-2026-31594: PCI: endpoint: pci-epf-vntb: Remove duplicate resource teardown
In the Linux kernel, the following vulnerability has been resolved:
PCI: endpoint: pci-epf-vntb: Remove duplicate resource teardown
epfntbepcdestroy() duplicates the teardown that the caller is supposed to perform later. This leads to an oops when .allowlink fails or when .droplink is performed. The following is an example oops of the former case:
Unable to handle kernel paging request at virtual address dead000000000108 [...] [dead000000000108] address between user and kernel address ranges Internal error: Oops: 0000000096000044 [#1] SMP [...] Call trace: pciepcremoveepf+0x78/0xe0 (P) pciprimaryepcepflink+0x88/0xa8 configfssymlink+0x1f4/0x5a0 vfssymlink+0x134/0x1d8 dosymlinkat+0x88/0x138 arm64syssymlinkat+0x74/0xe0 [...]
Remove the helper, and drop pciepcput(). EPC device refcounting is tied to the configfs EPC group lifetime, and pciepcput() in the .droplink path is sufficient.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Operational
Apply the kernel code change that removes the duplicate resource teardown in the PCI endpoint driver pci-epf-vntb: remove the epf_ntb_epc_destroy() helper and drop the pci_epc_put() call (rely on pci_epc_put() in the .drop_link path and EPC device refcounting tied to the configfs EPC group lifetime). Rebuild and deploy the updated kernel containing this change.
Event History
Frequently Asked Questions
Which systems and configurations are realistically exposed?
Systems using the Linux kernel PCI endpoint framework with the pci-epf-vntb function are exposed. The issue is associated with failure of the .allow_link operation or execution of the .drop_link path; the provided data does not establish that ordinary default configurations are affected.
What access and conditions are required to exploit the issue?
An attacker or local user needs local access with low privileges, as reflected by the CVSS vector AV:L/PR:L/UI:N. Triggering the affected link-management paths can cause a kernel oops and denial of service; no confidentiality or integrity impact is indicated.
What can be done if patching is not immediately possible?
Apply a kernel update containing the removal of the duplicate teardown in pci-epf-vntb. If updating cannot occur immediately, avoid creating or changing PCI endpoint links through the affected configfs paths, particularly operations that can invoke .allow_link or .drop_link.
How can I tell whether this issue is occurring on a system?
A system may already be affected if it produces a kernel paging-request oops during PCI endpoint function linking or unlinking. The example trace includes pci_epc_remove_epf, pci_primary_epc_epf_link, configfs_symlink, and __arm64_sys_symlinkat.