CVE-2026-43200

What it actually does

This is a local denial-of-service flaw in the Linux kernel PCI endpoint framework. The vulnerable code registers configfs unlink callbacks with the source and target parameters in the wrong order for primary and secondary endpoint-controller-to-endpoint-function unlink operations. When a privileged local user or process performs the affected unlink operation through configfs, the kernel can dereference an invalid pointer while logging or unbinding the PCI endpoint function, resulting in a kernel crash or panic. The impact is availability loss only; the published CVSS vector indicates local access, low attack complexity, required low privileges, no user interaction, and no confidentiality or integrity impact.

Why it matters to the business

Successful exploitation can abruptly crash affected Linux systems that expose and use the PCI endpoint configfs interface, causing service interruption, failed workloads, device downtime, or disruption to embedded, appliance, telecom, edge, or test systems that rely on PCI endpoint functionality. The current EPSS is very low and has not increased over 30 days, it is not in CISA KEV, and no public exploit maturity is reported, so broad opportunistic exploitation is unlikely; however, systems where untrusted or semi-trusted local users can access PCI endpoint configfs should treat this as a meaningful availability risk.

How an attack unfolds

An attacker first needs local access to an affected Linux system with sufficient privileges to manipulate configfs entries for the PCI endpoint subsystem. They identify an existing PCI endpoint controller/function link under configfs, then issue an unlink operation, commonly through a filesystem operation such as unlink or rm against the relevant configfs link. Because the vulnerable kernel passes the configfs callback arguments in the wrong order during unlink handling, the PCI endpoint unlink path operates on the wrong object and may access an invalid address. This can trigger an oops, panic, or fatal kernel fault, taking the host or device offline until it is rebooted or otherwise recovered.

How to fix it

Apply a Linux kernel update that includes the upstream fix for the PCI endpoint configfs unlink callback parameter ordering issue. Because no exact fixed package versions were provided, use the patched kernel versions published by the relevant Linux distribution, appliance vendor, board support package provider, or long-term stable kernel branch. Reboot into the updated kernel after installation. Where immediate patching is not possible, restrict local access to systems exposing PCI endpoint configfs, limit sudo or administrative workflows that can modify /sys/kernel/config, avoid granting untrusted users access to configfs management operations, and disable or avoid loading PCI endpoint functionality on systems that do not require it.

How to confirm the fix worked

Confirm the running kernel includes the vendor or upstream fix, not merely that packages are installed. Validate with uname -a, distribution package metadata, and vendor advisories for the deployed kernel stream. Check whether configfs is mounted, commonly at /sys/kernel/config, and whether PCI endpoint entries exist under /sys/kernel/config/pci_ep. On patched test systems, controlled unlink operations against valid PCI endpoint configfs links should no longer produce kernel oops or panic messages. Also confirm that access controls prevent non-administrative users from modifying configfs PCI endpoint objects.

Typical attack path

1. Obtain local shell or code execution on an affected Linux system.
2. Confirm that configfs is mounted and that PCI endpoint configuration entries are present.
3. Use privileges capable of modifying configfs PCI endpoint objects.
4. Locate an established PCI endpoint controller to endpoint function link.
5. Perform an unlink operation against the affected configfs link.
6. Trigger the vulnerable PCI endpoint unlink callback path with swapped parameters.
7. Cause a kernel oops, panic, or crash, resulting in denial of service.

How to detect it

Look for evidence of prior local exploitation or accidental triggering in kernel logs, persistent journal entries, crash dumps, and audit logs. Relevant sources include dmesg, /var/log/kern.log, /var/log/messages, journalctl -k, systemd-coredump or kdump/vmcore records, auditd syscall logs for unlink/unlinkat operations under configfs, sudo logs, shell history for administrative users, and automation logs for hardware or PCI endpoint test frameworks. Focus on crashes that occurred immediately after unlink or rm operations targeting /sys/kernel/config/pci_ep paths. Kernel traces may show functions such as pci_epf_unbind, configfs_unlink, vfs_unlink, __arm64_sys_unlinkat, string, vsnprintf, or messages such as an inability to handle a kernel paging request. Because this is a local denial-of-service issue, there are no reliable network indicators; attribution should be based on local account activity, command execution records, and timing correlation with the kernel fault.

• /sys/kernel/config/pci_ep
• Unable to handle kernel paging request
• pci_epf_unbind
• configfs_unlink
• vfs_unlink
• __arm64_sys_unlinkat
• pci_primary_epc_epf_unlink
• pci_secondary_epc_epf_unlink
• unlinkat
• rm /sys/kernel/config/pci_ep
• kernel panic
• Oops:
• Mem abort info:
• pc : string+0x54/0x14c
• lr : vsnprintf+0x280/0x6e8

What your security team should do

• Prioritize patching affected Linux systems that use PCI endpoint functionality, especially embedded, edge, appliance, lab, telecom, or hardware enablement systems where local operators or automation can manipulate configfs.
• Inventory hosts with configfs mounted and PCI endpoint entries present under /sys/kernel/config/pci_ep.
• Restrict write access to configfs management operations to trusted administrators and tightly controlled automation only.
• Review sudoers, container privileges, maintenance scripts, and hardware test tooling for the ability to unlink or modify PCI endpoint configfs entries.
• Monitor kernel logs for PCI endpoint unlink activity followed by oops, panic, or paging request failures.
• Because EPSS is low, KEV status is false, and no mature exploit is reported, handle this as a targeted/local availability issue rather than an internet-scale emergency unless exposed in multi-user or semi-trusted local environments.