CVE-2026-53118

What it actually does

This is a Linux kernel use-after-free race in the vDPA bus driver matching path. During driver probing through __driver_attach(), the vDPA bus match callback could read the device driver_override field without holding the device lock. If that field is changed or freed concurrently, the kernel may dereference stale memory. Depending on kernel configuration, timing, and attacker control over vDPA device binding operations, the likely impacts are kernel crash/denial of service and, in higher-risk scenarios, potential kernel memory corruption that could support local privilege escalation.

Why it matters to the business

Systems using Linux kernels with vDPA support, especially virtualization, networking, or accelerator hosts that expose vDPA device management, may be vulnerable to local disruption. A successful attack could crash a host kernel and interrupt workloads. There is no indication that this issue is in CISA KEV, used in ransomware campaigns, or currently has mature public exploitation; EPSS is low, so urgency is moderate unless vDPA is enabled on multi-user or virtualization infrastructure.

How an attack unfolds

An attacker would generally need local access or equivalent ability to manipulate vDPA device driver binding state. They would attempt to create a race between driver probing and updates to the driver_override attribute, causing the vDPA match routine to access freed memory. If the race is won, the kernel may crash or enter an unsafe memory state. Practical exploitation would require precise timing, a suitable vDPA-capable system, and enough permissions to interact with the relevant sysfs driver-binding interfaces. No named threat actors or active exploitation campaigns are currently associated with this vulnerability.

How to fix it

Upgrade to a Linux kernel version that includes the vDPA fix using the generic driver-core driver_override infrastructure. If vendor fixed package versions are not yet available, track kernel updates from the relevant Linux distribution or appliance vendor and apply the first security update that references this issue or the vDPA driver_override locking fix. As interim mitigation, reduce exposure by disabling unused vDPA modules/features, restricting local shell access on systems with vDPA devices, limiting privileged access to sysfs driver binding paths, and applying standard kernel hardening such as lockdown, module loading restrictions, and least-privilege administrative controls.

How to confirm the fix worked

Confirm the running kernel includes the vendor fix for this vulnerability, not only that an updated package is installed. Validate with the distribution security advisory, kernel changelog, or source patch history showing vDPA has been moved to the generic driver_override infrastructure. Check whether vDPA is present or loaded using kernel module inventory and sysfs paths such as /sys/bus/vdpa. Where safe, verify that the system no longer exposes the vulnerable code path by confirming the updated kernel is running after reboot and that no older vulnerable kernel remains the default boot entry.

Typical attack path

1. Gain local code execution on a Linux system with vulnerable kernel vDPA support enabled or loaded.
2. Identify available vDPA devices and driver binding interfaces under sysfs.
3. Repeatedly modify or clear the vDPA device driver_override attribute while triggering driver attach, unbind, bind, or reprobe operations.
4. Win the race condition so the vDPA match path reads a stale driver_override pointer.
5. Cause a kernel oops/panic for denial of service, or attempt to shape memory reuse for further kernel exploitation.

How to detect it

Look for evidence of prior exploitation in kernel logs, audit logs, and endpoint telemetry around vDPA driver binding operations. Relevant sources include journalctl/kern.log/dmesg, auditd records for sysfs writes, EDR process telemetry showing repeated writes to driver_override or bind/unbind files, and crash dumps or vmcore analysis. Suspicious patterns include repeated modifications under /sys/bus/vdpa/devices/, kernel messages mentioning use-after-free, KASAN, slab corruption, general protection faults, or oops/panic events near vDPA, driver_override, __driver_attach, or driver binding activity. Absence of these artifacts does not prove non-exploitation because a successful kernel crash may leave limited logs, especially if persistent logging or crash capture was not enabled.

• /sys/bus/vdpa/devices/*/driver_override
• /sys/bus/vdpa/drivers/*/bind
• /sys/bus/vdpa/drivers/*/unbind
• driver_override
• __driver_attach
• vdpa
• BUG: KASAN: use-after-free
• use-after-free
• general protection fault
• kernel BUG
• kernel NULL pointer dereference
• Oops:
• Kernel panic
• slab-use-after-free

What your security team should do

• Inventory Linux systems for vDPA usage, prioritizing virtualization hosts, network acceleration platforms, and systems exposing /sys/bus/vdpa.
• Apply the relevant vendor kernel update and reboot into the fixed kernel when available.
• Prioritize patching higher on shared, multi-user, container-hosting, or virtualization systems where local users may influence device binding behavior.
• If immediate patching is not possible, disable unused vDPA functionality and restrict administrative access capable of writing to sysfs driver binding controls.
• Monitor kernel logs for use-after-free, KASAN, oops, panic, or vDPA driver binding anomalies.
• Add audit coverage for writes to vDPA driver_override, bind, and unbind sysfs paths on systems where vDPA is enabled.
• Because public exploit maturity is currently none and EPSS is low, treat this as a defense-in-depth kernel update unless local untrusted users or exposed virtualization management workflows are present.