CVE-2026-43211: Linux Kernel Race Condition Vulnerability

CVE-2026-43211 Overview

CVE-2026-43211 is a Linux kernel locking flaw in the PCI subsystem function pci_slot_trylock(). A prior commit, a4e772898f8b ("PCI: Add missing bridge lock to pci_bus_lock()"), delegated the bridge device's pci_dev_trylock() call to pci_bus_trylock(). However, the corresponding pci_dev_unlock(dev) call on the failure path was not removed. The result is an unbalanced unlock when pci_bus_trylock() fails. The condition produces either a kernel warning that a lock is being released while unheld, or an incorrect unlock of a lock owned by another thread. The issue has been resolved in upstream Linux kernel commits.

Critical Impact
An unbalanced lock release in pci_slot_trylock() can corrupt PCI bus locking state, leading to kernel warnings, race conditions, or unlocking a lock held by an unrelated thread.

Affected Products

Linux kernel versions containing commit a4e772898f8b ("PCI: Add missing bridge lock to pci_bus_lock()") prior to the fix
Linux kernel PCI subsystem (drivers/pci/) — pci_slot_trylock() code path
Stable kernel branches that backported the offending commit, as referenced in multiple git.kernel.org/stable fix commits

Discovery Timeline

2026-05-06 - CVE-2026-43211 published to NVD
2026-05-06 - Last updated in NVD database

Technical Details for CVE-2026-43211

Vulnerability Analysis

The defect resides in the Linux kernel PCI subsystem [CWE category: kernel locking / unbalanced lock release]. The function pci_slot_trylock() previously acquired the bridge device lock with pci_dev_trylock(dev) and, on failure to lock the subordinate bus via pci_bus_trylock(dev->subordinate), released that bridge lock with pci_dev_unlock(dev). Commit a4e772898f8b removed the explicit pci_dev_trylock(dev) acquisition, folding the bridge lock into pci_bus_trylock(). The corresponding pci_dev_unlock(dev) on the failure path was not removed. When pci_bus_trylock() fails, the kernel calls pci_dev_unlock() on a lock the current thread never acquired.

Root Cause

The root cause is an incomplete refactor of lock ownership semantics. After the locking responsibility moved into pci_bus_trylock(), the failure path retained the legacy pci_dev_unlock(dev) call. This produces one of two outcomes: a WARN triggered by lockdep or the mutex layer when an unheld lock is released, or an out-of-band unlock that strips the lock from a different thread that legitimately holds it.

Attack Vector

The code path is reachable through PCI hot-plug or device-rescan operations that call pci_slot_trylock(). The defect is primarily a stability and concurrency correctness issue rather than a documented remote attack vector. Releasing a lock held by another thread can produce race conditions in PCI device enumeration and reset paths. No public exploit is associated with this CVE, and it is not listed in the CISA Known Exploited Vulnerabilities catalog.

The fix removes the redundant pci_dev_unlock(dev) call on the pci_bus_trylock() failure path. Refer to the upstream commits, including kernel commit 9368d1ee62 and kernel commit a19b61fdb9, for the exact source change.

Detection Methods for CVE-2026-43211

Indicators of Compromise

Kernel WARN or WARNING messages referencing mutex or lock release without ownership in pci_slot_trylock or pci_dev_unlock stack frames.
Lockdep splats in dmesg pointing to PCI bus or slot locking during hot-plug, rescan, or reset operations.
Sporadic PCI device enumeration failures or hangs correlated with concurrent slot operations.

Detection Strategies

Parse kernel ring buffer (dmesg, /var/log/kern.log) for lock-imbalance warnings tied to PCI symbols.
Compare running kernel version and patch level against the fix commits referenced on git.kernel.org/stable to identify unpatched hosts.
Enable CONFIG_PROVE_LOCKING in test environments to surface the imbalance during PCI slot operations.

Monitoring Recommendations

Forward kernel logs to a centralized logging or SIEM pipeline and alert on pci_slot_trylock, pci_dev_unlock, and lockdep warning patterns.
Track PCI hot-plug and rescan events on systems that perform frequent device add/remove cycles, such as virtualization hosts and storage servers.
Inventory Linux kernel build versions across the fleet and flag hosts running a kernel that contains a4e772898f8b without the fix commit.

How to Mitigate CVE-2026-43211

Immediate Actions Required

Identify Linux hosts running kernel versions that include commit a4e772898f8b but not the corrective fix commits listed in the NVD references.
Apply the upstream stable kernel update containing the fix, then reboot to load the patched kernel.
Prioritize systems that exercise PCI hot-plug, SR-IOV reconfiguration, or frequent device rescans.

Patch Information

The fix is available across multiple Linux stable branches. Apply the vendor-supplied kernel update or pull the upstream fix from one of the following references: kernel commit 0425aaf20b, kernel commit 8b08ea9690, kernel commit 9368d1ee62, kernel commit 943ed56606, kernel commit a19b61fdb9, kernel commit bd435f4b73, kernel commit ebb27b7399, and kernel commit fbe06a3058.

Workarounds

Avoid concurrent PCI slot lock operations and minimize PCI hot-plug or rescan activity on unpatched kernels until the fix is applied.
Where supported, restrict access to interfaces that trigger pci_slot_trylock() paths, such as /sys/bus/pci/rescan and slot power controls, to trusted administrators.
Build and deploy a hotpatched kernel that applies only the single-hunk removal of the redundant pci_dev_unlock(dev) call if a full vendor update is not yet available.

bash

# Verify whether the running kernel includes the fix commit
uname -r
zgrep -E 'pci_slot_trylock|pci_dev_unlock' /proc/kallsyms

# Example: apply vendor stable kernel update (Debian/Ubuntu)
sudo apt-get update && sudo apt-get install --only-upgrade linux-image-generic
sudo reboot

# Example: apply vendor stable kernel update (RHEL/CentOS/Rocky)
sudo dnf update kernel
sudo reboot

# Watch kernel log for lock imbalance warnings
sudo dmesg -w | grep -iE 'pci_slot_trylock|pci_dev_unlock|lockdep'