HIGH 7.8

CVE-2026-53120: Linux Kernel PCI Driver Use-After-Free Local Privilege Escalation (CVSS 7.8)

A use-after-free vulnerability exists in the Linux kernel's PCI driver handling code. When the kernel attempts to attach a driver to a PCI device, it accesses configuration data (driver_override) without proper synchronization. An attacker with local access could potentially exploit this race condition to read sensitive kernel memory, modify kernel data, or execute code with kernel privileges. The vulnerability affects Linux kernel versions that use the affected PCI probe path.

Source data · NVD / CISA · public domain

CVSS
3.1 · 7.8 HIGH · CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Weaknesses (CWE)
CWE-416
Affected products
1 configuration(s)
Published / Modified
2026-06-24 / 2026-07-23

NVD description (verbatim)

In the Linux kernel, the following vulnerability has been resolved: PCI: use generic driver_override infrastructure When a driver is probed through __driver_attach(), the bus' match() callback is called without the device lock held, thus accessing the driver_override field without a lock, which can cause a UAF. Fix this by using the driver-core driver_override infrastructure taking care of proper locking internally. Note that calling match() from __driver_attach() without the device lock held is intentional. [1]

4 reference(s) · View on NVD →

SEC.co analysis · AI-assisted, reviewed against source

Technical summary

CVE-2026-53120 is a use-after-free (UAF) vulnerability in the Linux kernel's PCI subsystem, specifically in the driver probe pathway. The issue occurs when __driver_attach() invokes the bus' match() callback without holding the device lock, creating an unsynchronized access window to the driver_override field. This allows concurrent modification or deallocation of the field while it is being read, violating memory safety. The fix involves migrating PCI's driver_override implementation to use the driver-core's generic driver_override infrastructure, which enforces proper locking semantics internally. The underlying design decision to call match() without the device lock is intentional per kernel architecture notes, necessitating synchronization at the field access level rather than the callback level.

Business impact

Successful exploitation enables local privilege escalation and potential kernel memory corruption. An unprivileged local user can trigger the race condition to achieve code execution at kernel level, compromising system integrity, confidentiality, and availability. For organizations running Linux-based infrastructure (servers, containers, embedded systems), this represents a significant risk to defense-in-depth posture, particularly in shared or multi-tenant environments. Patching is critical before exposing systems to untrusted local users.

Affected systems

The Linux kernel is affected. The vulnerability is present in kernel versions that have not yet integrated the driver-core generic driver_override infrastructure into the PCI subsystem. Check your kernel version and patch status against the vendor's official Linux kernel security advisories to determine precise affected releases and backport availability for your distribution (RHEL, Ubuntu, Debian, SUSE, etc.).

Exploitability

Exploitability is moderate to high. The vulnerability requires local access (CWE-416 use-after-free with AV:L) and is not gated behind special privileges—a standard user account suffices (PR:L). No user interaction or complex setup is required (AC:L, UI:N). The race condition window is narrow but feasible to trigger repeatedly. However, reliable exploitation may require kernel-specific knowledge and timing tuning. The CVSS 3.1 score of 7.8 (HIGH) reflects the severity of impact (C:H, I:H, A:H) balanced against the local-access prerequisite.

Remediation

Apply the Linux kernel patch that integrates PCI driver_override handling into the driver-core generic infrastructure. This is typically available as a stable kernel update or backport from the upstream fix. Verify the patch against your distribution's security advisory—many stable distributions (RHEL, Ubuntu LTS, Debian) will release kernel updates addressing this issue. If in-place patching is not immediately feasible, restrict local access to affected systems and disable PCI hotplug or driver override mechanisms if operationally safe.

Patch guidance

Consult your Linux distribution's official security advisory and kernel update channels. Major distributions will publish patched kernel versions; install via your package manager (apt, yum, dnf, zypper). Test patches in a staging environment first, as kernel updates require validation for your specific hardware and workload. Reboot is required to activate the patched kernel. Verify the running kernel version post-update using `uname -r`.

Detection guidance

Detection at the application level is difficult due to the in-kernel nature of the vulnerability. Monitor kernel logs for UAF-related warnings or panics, particularly around PCI driver binding events (dmesg, journalctl). Intrusion detection systems may flag anomalous local process behavior or privilege escalation attempts. The best detection strategy is proactive: maintain kernel patch currency and use security scanning tools (e.g., kernel Live Patch readiness checks) to identify unpatched systems in your inventory. Runtime behavioral analysis for unexpected kernel memory access patterns may also surface exploitation attempts in high-security environments.

Why prioritize this

This vulnerability merits immediate prioritization due to its HIGH CVSS score (7.8), local privilege escalation capability, and straightforward exploit path. It affects a core kernel subsystem with broad exposure across Linux deployments. The lack of KEV (Known Exploited Vulnerability) status does not diminish risk; the vulnerability's technical simplicity and high impact make it an attractive target. Prioritize patching systems in order of: (1) multi-user or shared-access systems, (2) containers or cloud infrastructure, (3) critical servers, (4) single-user workstations.

Risk score, explained

The CVSS 3.1 score of 7.8 (HIGH) reflects: Attack Vector Local (AV:L) – attacker must have local system access; Attack Complexity Low (AC:L) – exploit does not require special conditions; Privileges Required Low (PR:L) – standard user rights suffice; User Interaction None (UI:N) – automated exploitation is possible; Scope Unchanged (S:U) – impact is isolated to the affected system; and maximum impact on Confidentiality, Integrity, and Availability (C:H, I:H, A:H) – kernel-level compromise affects all three pillars. The score accurately captures a serious local privilege escalation that demands prompt remediation.

Frequently asked questions

Can this be exploited remotely?

No. CVE-2026-53120 requires local access (AV:L) and cannot be exploited over the network. An attacker must have a user account or shell access on the affected system.

Do I need to patch if my systems do not allow local users?

Lower your risk by patching anyway. If your threat model strictly excludes local attackers (e.g., single-user workstations in your control, bare-metal servers with no multi-tenancy), patching urgency can be deferred slightly. However, supply-chain or insider threats may introduce local access; patching remains strongly recommended.

Will a kernel Live Patch or hotpatch resolve this?

Some distributions (RHEL, Ubuntu) offer Live Patching. Check your distribution's Live Patch service to see if this CVE is covered. Live Patch can address the vulnerability without rebooting, reducing operational disruption, though a reboot-and-patch approach is equally effective.

How long has this vulnerability existed in the kernel?

The exact introduction date is not provided in this advisory; consult the upstream Linux kernel commit history and your distribution's advisory for timeline details. The publish date (2026-06-24) indicates when it was formally disclosed.

This analysis is provided for informational purposes and is based on the published vulnerability data as of the date of this report. Patch versions, affected releases, and remediation timelines are vendor-specific and must be verified against official Linux distribution security advisories (kernel.org, Red Hat, Ubuntu, Debian, SUSE, etc.). No exploit code or attack details are provided or intended. Always test patches in non-production environments before deploying to critical systems. SEC.co makes no warranty regarding the completeness or accuracy of third-party vendor patch status; consult your distribution's official channels for authoritative guidance. Source: NVD (public-domain), retrieved 2026-08-02. Analysis generated by SEC.co (claude-haiku-4-5).