CVE-2026-53120

What it actually does

This Linux kernel flaw is a use-after-free condition in PCI driver matching. During driver probing via __driver_attach(), the PCI bus match() callback can access the device's driver_override field without holding the device lock. If driver_override is concurrently modified or freed, kernel code may dereference stale memory. Depending on timing, this can cause a kernel crash, memory corruption, or potentially privilege-impacting behavior in kernel context. The upstream fix moves PCI to the generic driver-core driver_override infrastructure, which provides the required internal locking.

Why it matters to the business

The most likely operational impact is host instability or denial of service on Linux systems using affected kernel versions, especially where PCI device binding, unbinding, hot-plug behavior, virtualization, or driver override workflows are used. Exploitation maturity is currently reported as none, EPSS is very low, and this is not listed in CISA KEV or ransomware exploitation, so broad active exploitation is not indicated. However, because the issue is in the kernel, a successful exploit or accidental trigger can disrupt workloads, hypervisors, appliances, or embedded systems that depend on the affected kernel.

How an attack unfolds

An attacker would need a way to influence PCI driver binding behavior or trigger concurrent driver probing and driver_override changes on an affected Linux system. In a plausible local attack scenario, the attacker repeatedly manipulates PCI device driver override state through exposed kernel interfaces while causing driver probe or attach paths to run, attempting to win a race where match() reads driver_override after it has been freed or replaced. If the race is won, the kernel may dereference freed memory, typically resulting in a crash. More advanced exploitation would require shaping reclaimed kernel memory and bypassing kernel hardening to convert the use-after-free into controlled memory corruption. There is no current indication of public exploit maturity or known in-the-wild exploitation.

How to fix it

Upgrade to a Linux kernel build that includes the upstream fix for PCI driver_override locking by using the generic driver-core driver_override infrastructure. Because no affected product list or fixed package versions were provided, use vendor-specific advisories for the deployed distribution or appliance kernel and install the first kernel release that includes the fix for CVE-2026-53120. Reboot systems after kernel updates to ensure the fixed kernel is running. Where immediate patching is not possible, reduce exposure by restricting local administrative access, limiting untrusted access to sysfs driver binding controls, disabling unnecessary PCI hot-plug or device passthrough workflows where feasible, and applying standard kernel hardening controls such as lockdown mode, module restrictions, and least-privilege access to device management interfaces.

How to confirm the fix worked

Confirm the running kernel, not only the installed package, has been updated. On Linux systems, compare `uname -r` and distribution package metadata against the vendor advisory containing the fix. If building from source, verify the PCI subsystem uses the generic driver-core driver_override infrastructure and no longer performs unlocked direct access to the PCI device driver_override field in the vulnerable match path. Validate that systems have been rebooted into the fixed kernel. For exposure review, identify hosts that permit PCI driver binding changes, hot-plug operations, VFIO/device passthrough, or administrative manipulation of `/sys/bus/pci/drivers/*` and prioritize them for patching.

Typical attack path

1. Obtain local access or another capability that can influence PCI device driver binding, driver override, hot-plug, or probe behavior.
2. Identify that the running kernel contains the vulnerable PCI driver_override handling.
3. Repeatedly modify or clear driver_override state while triggering PCI driver probe or attach operations.
4. Attempt to create a race where __driver_attach() invokes the PCI match() callback while driver_override memory is concurrently freed or changed.
5. Cause a kernel fault or memory corruption when stale driver_override memory is accessed.
6. Optionally attempt advanced kernel exploitation by reclaiming freed memory with attacker-controlled data, if practical against the target kernel and hardening configuration.

How to detect it

There are no unique public exploitation indicators for this vulnerability. Detection should focus on evidence of attempted race triggering and resulting kernel instability. Review kernel logs, system journals, crash dumps, and audit logs for PCI driver binding, unbinding, driver_override changes, and kernel oops or panic events around PCI probing. Relevant sources include `dmesg`, `/var/log/kern.log`, `/var/log/messages`, `journalctl -k`, auditd records for writes under `/sys/bus/pci/`, kernel crash dump facilities such as kdump/vmcore, and EDR telemetry showing processes repeatedly writing to sysfs PCI driver control files. Look for high-frequency or unusual writes to PCI `driver_override`, `bind`, `unbind`, `new_id`, or `remove_id` interfaces, especially followed by kernel faults containing PCI, driver core, `__driver_attach`, or match callback frames. Because exploitation would likely be local and timing-dependent, absence of these indicators does not prove non-exploitation.

• /sys/bus/pci/devices/*/driver_override
• /sys/bus/pci/drivers/*/bind
• /sys/bus/pci/drivers/*/unbind
• /sys/bus/pci/drivers/*/new_id
• /sys/bus/pci/drivers/*/remove_id
• __driver_attach
• driver_override
• BUG: unable to handle page fault
• general protection fault
• kernel NULL pointer dereference
• kernel panic
• Oops:
• PCI:
• probe of * failed

What your security team should do

• Patch affected Linux kernels through the operating system or appliance vendor and reboot into the fixed kernel.
• Prioritize systems where untrusted users, containers, tenants, or automation can influence device binding, PCI hot-plug, VFIO, or driver override behavior.
• Restrict write access to sysfs PCI driver binding and override interfaces to trusted administrators only.
• Review virtualization hosts, GPU/accelerator passthrough servers, lab systems, and embedded Linux devices that frequently rebind PCI devices.
• Monitor for kernel crashes, oops messages, or suspicious repeated PCI driver bind/unbind activity until patching is complete.
• Track vendor advisories for exact fixed kernel package versions because no product-specific fixed versions were provided in the input.
• Do not treat this as currently known exploited based on available data: EPSS is low, exploit maturity is none, and it is not in CISA KEV.