CVE-2026-53119

What it actually does

This is a Linux kernel use-after-free condition in the WMI platform bus driver matching path. During driver probing via __driver_attach(), the bus match() callback could read a device's driver_override field without holding the device lock. If that field is changed or freed concurrently, the kernel may dereference stale memory. The most likely technical outcomes are kernel crash, denial of service, or undefined kernel behavior; depending on allocator state and reachable race conditions, kernel memory corruption could potentially be leveraged for local privilege escalation, although no public exploit maturity is currently indicated.

Why it matters to the business

Systems running vulnerable Linux kernels may be exposed to local stability and availability risk, especially where untrusted users, containers with elevated device/sysfs access, or local management agents can interact with kernel driver binding interfaces. Because this affects kernel code, a successful exploit can impact the entire host rather than a single application. Current public exploitation signals are low: EPSS is 0.0012, it is not listed in CISA KEV, and no ransomware association is reported, so remediation should be handled through normal kernel patch cycles unless the environment exposes local device-management interfaces to less-trusted users.

How an attack unfolds

An attacker would need local access or another path to influence WMI device driver binding behavior, typically through sysfs driver override or driver probe/rebind mechanisms that require elevated privileges or delegated device-management rights. The attacker attempts to race updates to the WMI device's driver_override value against kernel driver probing, causing the match callback to access memory after it has been freed. If the race is won, the immediate effect may be a kernel oops or panic. More advanced exploitation would require shaping freed kernel memory so the stale pointer references attacker-influenced data, which could theoretically lead to kernel memory corruption or privilege escalation, but there is no indication of mature public exploitation at this time.

How to fix it

Upgrade to a Linux kernel version that includes the fix to use the generic driver_override infrastructure for WMI platform devices, which provides proper locking around driver_override access. If vendor kernel packages are used, apply the relevant distribution security update rather than attempting to patch upstream code manually. No exact fixed package versions were provided in the input, so administrators should consult their Linux distribution, appliance, cloud image, or embedded platform advisory for the first kernel build containing the CVE-2026-53119 fix. As interim risk reduction, restrict local shell access, limit sudo/root delegation, avoid granting containers or workloads access to host sysfs device binding paths, and monitor for unusual driver unbind/rebind or driver_override activity.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel package or source tree includes the WMI driver_override locking fix and that the system has rebooted into the patched kernel. Package installation alone is insufficient if the host is still running an older kernel. Validate exposure by inventorying Linux hosts with WMI support and checking whether /sys/bus/wmi/devices/*/driver_override or related bind/unbind controls are present and writable by non-administrative principals. For source-based validation, review the platform WMI driver code path to ensure it uses the generic driver-core driver_override helpers rather than directly accessing the driver_override field without appropriate locking.

Typical attack path

1. Obtain local shell access or code execution on a Linux host running an affected kernel.
2. Identify accessible WMI bus devices and driver binding controls exposed through sysfs.
3. Repeatedly modify driver_override or related binding state while triggering driver probe, unbind, or rebind activity.
4. Race the unlocked match() callback so it reads driver_override after the backing memory has been freed or replaced.
5. Cause a kernel crash, or in a more advanced scenario, attempt to shape freed memory to influence kernel control flow or data structures.
6. Use any resulting kernel memory corruption primitive to disrupt the host or attempt privilege escalation.

How to detect it

To assess possible prior exploitation, review kernel and system logs for crashes, oops traces, warnings, or panics involving WMI, driver_override, __driver_attach, driver_probe_device, or driver binding and matching functions. Useful log sources include journalctl -k, /var/log/kern.log, /var/log/messages, /var/log/syslog, persistent pstore/ramoops records, crash dumps, kdump vmcores, and EDR telemetry that records writes to sysfs. Look for repeated writes to /sys/bus/wmi/devices/*/driver_override or unusually frequent bind/unbind/rebind activity around the time of a kernel crash. Since exploitation is race-based and kernel-resident, there may be no durable file artifact; absence of logs does not prove absence of exploitation, especially if the host rebooted without persistent kernel logging. There are no known public attacker-specific indicators or threat actor patterns associated with this issue based on the provided data.

• /sys/bus/wmi/devices/*/driver_override
• /sys/bus/wmi/drivers/*/bind
• /sys/bus/wmi/drivers/*/unbind
• driver_override
• __driver_attach
• platform/wmi
• wmi:
• BUG: kernel NULL pointer dereference
• BUG: unable to handle page fault
• general protection fault
• KASAN: use-after-free
• kernel BUG at drivers/platform/x86/wmi.c
• Oops:
• Kernel panic - not syncing

What your security team should do

• Inventory Linux kernel versions across servers, workstations, appliances, and container hosts, prioritizing systems where local users or semi-trusted workloads exist.
• Apply vendor kernel updates that include the WMI driver_override fix, then reboot and verify the patched kernel is active.
• Treat multi-user Linux systems, developer workstations, CI runners, virtualization hosts, and container hosts as higher priority because local kernel bugs can cross trust boundaries.
• Restrict write access to sysfs driver binding and driver_override interfaces to trusted administrators only.
• Review sudoers, container runtime, and orchestration policies for unnecessary host device, privileged container, or host /sys mounts.
• Monitor kernel logs for suspicious WMI driver binding activity, kernel oops events, or crashes involving platform/wmi, driver_override, __driver_attach, or driver matching paths.
• Because EPSS is low, the issue is not in KEV, and no exploit maturity is reported, handle through standard patch management unless compensating factors increase local attacker exposure.