CVE-2026-43211

What it actually does

This is a Linux kernel locking error in the PCI subsystem. A prior change moved bridge-device locking into pci_bus_trylock(), but an old pci_dev_unlock() call remained on an error path in pci_slot_trylock(). When pci_bus_trylock() fails, the kernel may attempt to unlock a PCI device lock that was not acquired by the current path. Depending on timing, this can produce a kernel lock warning or incorrectly release a lock owned by another thread. In the worst case, that can corrupt kernel synchronization assumptions and create race conditions affecting confidentiality, integrity, and availability on the local host.

Why it matters to the business

Successful exploitation could allow a local user or compromised local process to destabilize a Linux system, interfere with PCI device handling, or potentially gain elevated control through kernel memory or synchronization corruption. This is most relevant for multi-user Linux servers, virtualization hosts, systems exposing PCI hotplug/VFIO/device-management features, and environments where untrusted workloads can interact with hardware-management interfaces. The EPSS score is very low, there is no CISA KEV listing, no ransomware association, and no public exploit maturity reported, so broad internet-scale exploitation is not currently indicated; however, kernel flaws should still be prioritized because successful local exploitation can be severe.

How an attack unfolds

An attacker first obtains local code execution with low privileges on a vulnerable Linux system. They then trigger PCI slot or bus-management code paths that call pci_slot_trylock(), ideally creating timing pressure so that pci_bus_trylock() fails while another thread holds or contends for the related PCI bus or bridge lock. On the vulnerable error path, the kernel executes pci_dev_unlock(dev) even though that path did not acquire the corresponding device lock. This may simply generate a lock warning, but under the right concurrency conditions it can release another thread’s lock and allow unsafe concurrent access to PCI device state. The attacker would then attempt to turn that synchronization failure into a kernel crash, device-state corruption, or a privilege-escalation primitive. No named threat actors or active exploitation campaigns are currently reported for this vulnerability.

How to fix it

Upgrade to a Linux kernel build that includes the upstream fix removing the redundant pci_dev_unlock(dev) call from the pci_bus_trylock() failure path in pci_slot_trylock(). Because no exact fixed versions were provided, use vendor advisories and distribution kernel changelogs to identify the first fixed kernel for each Linux distribution or appliance. Prefer vendor-supported kernel updates over manually backporting patches. If immediate patching is not possible, reduce exposure by limiting local shell access, restricting untrusted workloads, disabling or tightly controlling PCI hotplug/rescan and device-management interfaces where feasible, limiting VFIO/device passthrough access to trusted administrators, and ensuring kernel lockdown, module-loading restrictions, and least-privilege controls are enabled. Reboot is typically required after a kernel update for the fixed kernel to be active.

How to confirm the fix worked

Confirm the active kernel is fixed, not merely installed. Check the running kernel version with uname -r and compare it to the vendor’s fixed kernel package or advisory. Review distribution changelogs for references to the PCI pci_slot_trylock() fix, pci_dev_unlock() removal, or the upstream commit resolving the issue. Where source or build metadata is available, verify that pci_slot_trylock() no longer calls pci_dev_unlock(dev) on the pci_bus_trylock(dev->subordinate) failure path unless that lock was actually acquired. Confirm that hosts have been rebooted into the fixed kernel. For fleet validation, inventory Linux kernels across systems and flag versions known to contain the vulnerable PCI locking change without the subsequent correction.

Typical attack path

1. Gain local execution on a vulnerable Linux system, such as through a user shell, compromised service account, container escape precondition, or untrusted workload.
2. Identify whether the running kernel includes the affected PCI locking change but not the later fix.
3. Trigger PCI slot, PCI bus, hotplug, rescan, VFIO, or device-management operations that reach pci_slot_trylock().
4. Create lock contention or race timing so pci_bus_trylock() fails on the vulnerable path.
5. Cause the stale pci_dev_unlock() call to release an unheld or wrong lock.
6. Attempt to leverage the resulting race condition for denial of service, PCI state corruption, information exposure, or local privilege escalation.

How to detect it

Look for evidence of kernel lock misuse, PCI subsystem warnings, oopses, panics, or crashes that include pci_slot_trylock(), pci_dev_unlock(), pci_bus_trylock(), or related PCI bus locking functions. Relevant sources include dmesg, /var/log/kern.log, /var/log/messages, journald kernel logs, crash dumps, kdump/vmcore artifacts, EDR telemetry for kernel panics, and hypervisor or host-management logs on systems using PCI passthrough or hotplug. Suspicious activity would include repeated local triggering of PCI rescan, hotplug, VFIO bind/unbind, or device passthrough operations followed by lockdep warnings or system instability. Because no public exploit or stable exploit signature is known, detection should focus on behavioral correlation: local users or processes interacting with PCI management interfaces shortly before lock warnings, oopses, or unexpected reboots. Preserve kernel logs and crash dumps before rebooting or rotating logs, and correlate timestamps with audit logs, shell history, sudo logs, container runtime events, virtualization management logs, and sysfs writes under PCI device paths.

• pci_slot_trylock
• pci_dev_unlock
• pci_bus_trylock
• DEBUG_LOCKS_WARN_ON
• bad unlock balance
• trying to release lock
• is trying to release lock
• WARNING: bad unlock balance
• BUG: bad unlock balance
• kernel: WARNING
• kernel: BUG
• kernel: Oops
• lockdep
• PCI:
• /sys/bus/pci/rescan
• /sys/bus/pci/devices/
• /sys/bus/pci/drivers/
• /sys/bus/pci/slots/
• /sys/bus/pci/drivers_probe
• /sys/bus/pci/drivers_autoprobe

What your security team should do

• Prioritize patching Linux systems that allow local user access, run untrusted code, host containers or virtual machines, or expose PCI hotplug, VFIO, GPU, NVMe, NIC passthrough, or hardware-management workflows.
• Use vendor-supported kernel packages and reboot systems into the fixed kernel; do not rely on package installation alone.
• Review kernel logs for lockdep warnings, PCI subsystem warnings, unexplained kernel oopses, or crashes involving pci_slot_trylock(), pci_dev_unlock(), or pci_bus_trylock().
• Restrict access to PCI sysfs management operations, device passthrough, and hardware-management tooling to trusted administrators until patching is complete.
• For virtualization and container platforms, evaluate whether tenants or untrusted workloads can influence PCI device operations, hotplug paths, or passthrough device lifecycles.
• Because EPSS is low and there is no KEV listing or known public exploit, treat this as important local kernel-hardening work rather than an active mass-exploitation emergency, unless high-risk multi-tenant or device-passthrough exposure exists.
• Ensure kernel crash collection and centralized logging are enabled so lock warnings and oops traces are retained for investigation.