CVE-2026-64254: NTB: epf: Avoid pci_iounmap() with offset when PEER_SPAD and CONFIG share BAR
In the Linux kernel, the following vulnerability has been resolved:
NTB: epf: Avoid pciiounmap() with offset when PEERSPAD and CONFIG share BAR
When BARPEERSPAD and BARCONFIG share one PCI BAR, the module teardown path ends up calling pciiounmap() on the same iomem with some offset, which is unnecessary and triggers a kernel warning like the following:
Trying to vunmap() nonexistent vm area (0000000069a5ffe8) WARNING: mm/vmalloc.c:3470 at vunmap+0x58/0x68, CPU#5: modprobe/2937 [...] Call trace: vunmap+0x58/0x68 (P) iounmap+0x34/0x48 pciiounmap+0x2c/0x40 ntbepfpciremove+0x44/0x80 [ntbhwepf] pcideviceremove+0x48/0xf8 deviceremove+0x50/0x88 devicereleasedriverinternal+0x1c8/0x228 driverdetach+0x50/0xb0 busremovedriver+0x74/0x100 driverunregister+0x34/0x68 pciunregisterdriver+0x34/0xa0 ntbepfpcidriverexit+0x14/0xfe0 [ntbhwepf] [...]
Fix it by unmapping only when PEERSPAD and CONFIG use difference bars.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Linux kernel (NTB: epf)to a version that resolves this vulnerability.Patch Avoid pci_iounmap() with offset when PEER_SPAD and CONFIG share BAR - Configuration
Modify the NTB epf PCI teardown path so that pci_iounmap() is called only when PEER_SPAD and CONFIG do not share the same PCI BAR; if PEER_SPAD and CONFIG share one PCI BAR, avoid pci_iounmap() with an offset that targets the same iomem region unnecessarily.
NTB epf teardown logic unmapping behavior = unmap only when PEER_SPAD and CONFIG use different BARs (different bars)
Event History
Frequently Asked Questions
Which systems are affected in practice?
Systems using the Linux kernel NTB endpoint-function driver are exposed when the PEER_SPAD and CONFIG regions share a single PCI BAR. The issue occurs during module or driver teardown, including removal of the ntb_hw_epf driver.
What access is required to exploit this issue?
An attacker needs local access and low privileges according to the supplied CVSS vector. No user interaction is required, but the provided data does not identify a specific attacker-controlled trigger beyond reaching the affected teardown path.
What can be done if patching is not immediately possible?
If the NTB endpoint-function driver is not needed, avoid loading it or unload it only with awareness that the warning may occur on affected systems. The supplied fix changes teardown behavior so the mapping is only unmapped separately when PEER_SPAD and CONFIG use different BARs.
How can I tell whether a system is affected?
Check kernel logs during removal or unloading of the ntb_hw_epf driver for a warning such as "Trying to vunmap() nonexistent vm area" with a stack trace containing pci_iounmap() and ntb_epf_pci_remove. The condition is specifically associated with PEER_SPAD and CONFIG sharing one PCI BAR.