CVE-2026-45989

What it actually does

This is a local Linux kernel use-after-free flaw in the Open Firmware/device tree unittest driver path. The vulnerable testdrv_probe() function incorrectly releases a device_node reference that is owned by the PCI/device model, then later reuses that same pointer when populating platform devices. If the reference count reaches zero, the pointer can reference freed kernel memory. A local attacker with the ability to trigger the affected probe path could potentially cause kernel memory corruption, leading to denial of service and, in a worst case, local privilege escalation or arbitrary kernel-code execution. The CVSS vector indicates local access, low attack complexity, low privileges required, no user interaction, and high confidentiality, integrity, and availability impact.

Why it matters to the business

Successful exploitation could allow a low-privileged local user or compromised local process to crash affected Linux systems or potentially gain elevated privileges. For organizations running Linux systems where the affected kernel code is present and reachable, this could affect workload availability, host isolation, and the integrity of sensitive processes. The issue is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, has low EPSS probability, and has no reported public exploit maturity, so urgency is lower than actively exploited kernel vulnerabilities but still important for standard kernel patch cycles.

How an attack unfolds

An attacker first needs local access to an affected Linux system with the vulnerable kernel code present and a reachable path to the relevant Open Firmware/device tree unittest driver probe behavior. The attacker then triggers the vulnerable probe sequence so that testdrv_probe() obtains a device_node pointer, applies an overlay, incorrectly decrements the reference count with of_node_put(), and later reuses the same pointer through of_platform_default_populate(). If the object was freed and memory is reused in a controlled or partially controlled way, the attacker may be able to corrupt kernel memory. Practical exploitation would require kernel-specific knowledge, heap-shaping, and bypassing modern kernel hardening; absent a public exploit, the most likely observable outcome is a kernel crash, panic, or KASAN-reported use-after-free.

How to fix it

Upgrade to a Linux kernel version that includes the upstream fix removing the erroneous of_node_put() call from testdrv_probe(). Because no exact fixed package versions were provided, use the fixed kernel releases or distribution security advisories from the relevant Linux vendor, then reboot into the patched kernel. Where immediate patching is not possible, reduce exposure by disabling or excluding unnecessary kernel unittest/debug functionality from production kernels, limiting local shell access, restricting the ability to load kernel modules, enforcing least privilege, and enabling kernel hardening features such as module signing, lockdown mode, SELinux/AppArmor, KASLR, SMEP/SMAP where supported, and panic/crash monitoring.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel is a vendor-patched build containing the fix for the Open Firmware unittest testdrv_probe() use-after-free. Validate both the installed package version and the active booted kernel with standard commands such as uname -a and the distribution package manager. If source validation is possible, confirm that testdrv_probe() no longer calls of_node_put() on pdev->dev.of_node before using the node in of_platform_default_populate(). Also confirm that vulnerable or unnecessary unittest/debug kernel components are not present in production configurations, and review kernel logs after patching for absence of KASAN, BUG, panic, or use-after-free reports tied to this code path.

Typical attack path

1. Gain low-privileged local access to an affected Linux host.
2. Determine whether the running kernel includes the vulnerable Open Firmware/device tree unittest driver code and whether the relevant probe path is reachable.
3. Trigger the affected testdrv_probe() sequence involving device_node handling and overlay application.
4. Cause the erroneous of_node_put() to prematurely release the device_node reference.
5. Force later reuse of the freed device_node pointer through of_platform_default_populate().
6. Attempt to turn the resulting kernel use-after-free into a crash, privilege escalation, or arbitrary kernel memory manipulation.

How to detect it

Detection of prior exploitation is difficult because this is a memory-corruption issue in kernel code and may leave no durable artifact if exploitation succeeds cleanly. Review kernel logs, persistent journal data, crash dumps, and monitoring telemetry for signs of kernel oops, panic, KASAN reports, slab corruption, refcount anomalies, or use-after-free messages involving the Open Firmware unittest driver path. Relevant log sources include dmesg output, /var/log/kern.log, /var/log/messages, systemd journal kernel facility records, crash dump directories, kdump/vmcore artifacts, and EDR telemetry that records local privilege escalation behavior. Investigate unexplained crashes or privilege changes on affected kernels, especially where log messages reference testdrv_probe(), of_node_put(), device_node handling, overlays, or of_platform_default_populate(). Because no public exploit maturity or named threat actors are reported, detections should focus on anomalous kernel fault evidence and suspicious local activity rather than known exploit signatures.

• KASAN: use-after-free
• BUG: KASAN: use-after-free
• use-after-free in testdrv_probe
• testdrv_probe
• of_platform_default_populate
• of_node_put
• device_node
• kernel BUG
• Oops:
• general protection fault
• slab-use-after-free
• refcount_t: underflow
• kernel panic
• /var/crash
• /var/lib/systemd/coredump
• vmcore

What your security team should do

• Prioritize patching during the normal kernel maintenance window; escalate if local multi-user access, untrusted workloads, or kernel debug/unittest functionality are present.
• Inventory Linux systems and identify kernels that include the affected Open Firmware/device tree unittest driver code path.
• Apply vendor kernel updates and reboot systems to ensure the fixed kernel is active, not merely installed.
• Where patching is delayed, restrict local interactive access and prevent untrusted users or workloads from exercising kernel test/debug functionality.
• Ensure kernel module loading is restricted through module signing, lockdown, and least-privilege administrative controls.
• Monitor kernel logs and crash telemetry for use-after-free, KASAN, BUG, oops, or panic messages involving testdrv_probe(), of_node_put(), or of_platform_default_populate().
• Treat any suspicious local privilege escalation attempt or unexplained kernel crash on an affected system as requiring forensic review.
• Track vendor advisories for exact fixed kernel package versions because fixed_versions were not supplied in the input.