CVE-2026-46009

What it actually does

CVE-2026-46009 is a local Linux kernel availability flaw in the PCI endpoint framework, specifically the pci-epf-ntb endpoint function. The vulnerable code performs duplicate teardown of PCI endpoint resources in epf_ntb_epc_destroy(), including reference/resource handling that should be performed later by the caller. When certain link-management paths occur, such as a failed .allow_link operation or a .drop_link operation, the duplicate cleanup can cause a kernel oops. The practical impact is local denial of service through a kernel crash or instability on systems where the PCI endpoint NTB function is available and a local user can exercise the relevant configfs-based PCI endpoint controls.

Why it matters to the business

Successful exploitation can crash or destabilize affected Linux systems, causing service interruption, failed workloads, or device downtime. The issue requires local privileges and has low EPSS, is not listed in CISA KEV, and has no known public exploit maturity in the supplied data, so the most likely business risk is disruption by an authenticated local user, misconfigured automation, or an already-compromised account rather than broad remote exploitation. Systems using Linux PCI endpoint functionality, embedded platforms, development boards, appliance platforms, or hardware test environments are more likely to be exposed than general-purpose servers that do not enable this subsystem.

How an attack unfolds

An attacker first needs local access to an affected Linux system with sufficient privileges to interact with the PCI endpoint configfs interface and the pci-epf-ntb endpoint function. They then create or manipulate a PCI endpoint NTB function through configfs and trigger a link-management path where .allow_link fails or .drop_link is invoked. Due to duplicate resource teardown in the vulnerable kernel code, the same endpoint-related resources can be released more than once or released in the wrong ownership context. This causes the kernel to hit an oops condition, potentially panicking the system depending on kernel panic-on-oops configuration, watchdog behavior, or workload sensitivity. The end result is loss of availability rather than data theft or privilege escalation based on the supplied vulnerability details.

How to fix it

Upgrade to a Linux kernel version that includes the upstream fix removing the duplicate pci-epf-ntb resource teardown and dropping the incorrect pci_epc_put() handling in this path. No exact fixed versions were provided in the input, so remediation teams should use their Linux distribution, appliance vendor, or kernel maintainer advisories to identify the first fixed kernel build for their branch. Where immediate patching is not possible, reduce exposure by disabling or not loading the pci-epf-ntb module if it is not required, restricting access to configfs, limiting root or administrative shell access, and preventing untrusted users or automation from manipulating /sys/kernel/config PCI endpoint objects. On systems where kernel oops causes a full panic, review panic_on_oops settings in line with operational requirements, but treat configuration changes only as a risk-reduction measure, not a fix.

How to confirm the fix worked

Confirm the running kernel has been updated to a vendor build that includes the pci-epf-ntb duplicate teardown fix. Validate that the installed and booted kernel versions match the remediated package, not just that a package is present on disk. Check whether pci-epf-ntb is loaded or available using module inventory commands and whether PCI endpoint configfs is mounted and populated under /sys/kernel/config. For exposure validation, verify that only trusted administrators can access configfs and that the PCI endpoint NTB function is not enabled on systems that do not require it. In lab or staging only, reproduce the relevant allow_link failure or drop_link workflow against the fixed kernel and confirm that no kernel oops occurs; do not run crash-triggering tests on production systems.

Typical attack path

1. Obtain local access to an affected Linux host or device.
2. Confirm that PCI endpoint support and the pci-epf-ntb function are present or loadable.
3. Gain sufficient privileges to manipulate PCI endpoint configfs objects, typically requiring root or equivalent administrative capability.
4. Create, bind, or modify a PCI endpoint NTB function under the PCI endpoint configfs hierarchy.
5. Trigger an error path in .allow_link or invoke .drop_link for the endpoint function.
6. Cause duplicate endpoint resource teardown in the vulnerable kernel path.
7. Induce a kernel oops, system instability, or a crash, resulting in denial of service.

How to detect it

To determine whether exploitation or accidental triggering already occurred, review kernel logs and persistent system journals for oops, panic, BUG, refcount, use-after-free, or crash events involving the PCI endpoint NTB driver. Relevant log sources include dmesg output, journald kernel logs, /var/log/kern.log, /var/log/messages, crash dump metadata, kdump/vmcore records, and EDR telemetry that captures kernel panic or reboot causes. Look for stack traces containing pci-epf-ntb, epf_ntb_epc_destroy(), pci_epc_put(), allow_link, or drop_link. Correlate any crash with preceding administrative actions under /sys/kernel/config/pci_ep/, module load/unload events for pci-epf-ntb, configfs mount activity, or automation that creates/destroys PCI endpoint functions. Because exploitation requires local control of PCI endpoint configuration, also review sudo, auditd, shell history, and privileged process execution logs for commands that write to PCI endpoint configfs paths or load the pci-epf-ntb module shortly before the crash. Absence of these artifacts does not fully rule out exploitation if volatile kernel logs were lost during reboot.

• epf_ntb_epc_destroy
• pci_epc_put
• pci-epf-ntb
• pci_epf_ntb
• allow_link
• drop_link
• /sys/kernel/config/pci_ep/
• Kernel panic - not syncing
• BUG: kernel NULL pointer dereference
• Oops:
• Call Trace:
• RIP: epf_ntb_epc_destroy
• modprobe pci-epf-ntb
• insmod pci-epf-ntb.ko
• pci-epf-ntb.ko

What your security team should do

• Identify Linux systems, embedded devices, appliances, and hardware test platforms that enable PCI endpoint functionality or load the pci-epf-ntb module.
• Prioritize patching systems where untrusted local users, CI jobs, hardware test automation, or delegated administrators can interact with configfs or PCI endpoint controls.
• Apply the vendor-provided fixed kernel and reboot into the fixed version; confirm the active kernel is remediated.
• If the pci-epf-ntb endpoint function is not required, disable or blacklist the module and remove unnecessary PCI endpoint configuration.
• Restrict administrative shell access and configfs access to trusted operators only.
• Monitor kernel logs for oops, panic, and stack traces involving pci-epf-ntb, epf_ntb_epc_destroy, allow_link, drop_link, or pci_epc_put.
• Treat any unexplained kernel oops involving PCI endpoint NTB functions as a potential denial-of-service attempt or unsafe automation event and preserve logs for investigation.
• Because this is not currently KEV-listed and has low EPSS, schedule remediation according to local exposure, giving higher urgency to shared, multi-user, lab, embedded, and appliance environments.