CVE-2026-63906

What it actually does

This vulnerability is a use-after-free in the Linux kernel USB MUSB OMAP2430 driver probe path. During omap2430_probe(), a device tree node reference can be released with of_node_put(np) before the code has finished using the pointer. If the reference count reaches zero, later access to that node can dereference freed kernel memory. Because this occurs in kernel space, successful exploitation could lead to memory corruption with potential confidentiality, integrity, and availability impact, including kernel crash or possible privilege escalation depending on platform configuration and exploitability.

Why it matters to the business

Systems using affected Linux kernels on hardware or configurations that load the OMAP2430 MUSB USB controller driver may be exposed to local kernel compromise or denial of service. The main operational risk is disruption from kernel crashes on embedded, appliance, industrial, or mobile/SoC-based Linux systems, with a secondary risk of local privilege escalation if an attacker can trigger the vulnerable probe path. EPSS is currently low and there is no known CISA KEV listing or public exploit maturity reported, but the CVSS score is high because successful exploitation affects the kernel.

How an attack unfolds

An attacker needs local ability to influence or trigger the vulnerable driver probe path, typically on a system where the OMAP2430 MUSB USB controller driver is present and relevant device tree data is processed. The vulnerable code releases a device tree node reference too early and later accesses that same pointer. If the freed object can be reclaimed or its contents influenced before the later access, the attacker may be able to cause controlled kernel memory corruption. In less controlled scenarios, exploitation may simply crash the kernel, producing a denial of service. Because the flaw is in a hardware-specific kernel driver, practical exploitation depends heavily on kernel build options, hardware platform, device tree configuration, module availability, and whether an unprivileged local user can cause the affected probe logic to run.

How to fix it

Upgrade to a Linux kernel version or vendor kernel package that includes the upstream fix moving of_node_put(np) until after the final access to np in both success and error paths of omap2430_probe(). Because no exact fixed versions were provided, use the security advisory from the operating system, appliance, embedded platform, or kernel distribution vendor to identify the corrected kernel build. Where immediate patching is not possible, reduce exposure by disabling or removing the affected OMAP2430 MUSB driver if it is not required, preventing untrusted users from loading kernel modules, restricting physical or local access to affected systems, and applying standard kernel hardening such as module signing, lockdown mode, SELinux/AppArmor policy, and least-privilege access controls.

How to confirm the fix worked

Confirm the running kernel package is at or above the vendor-fixed version and that the source or package changelog contains the OMAP2430 MUSB use-after-free fix. Verify whether the affected driver is present by checking kernel configuration and loaded modules for MUSB OMAP2430 support. On systems where the driver is not present, not loadable, or not applicable to the hardware/device tree, exposure is substantially reduced. After patching, reboot into the fixed kernel and verify with uname, package manager metadata, and vendor advisory references that the active kernel is the corrected build, not merely installed side-by-side.

Typical attack path

1. Identify a Linux system running an affected kernel with the OMAP2430 MUSB USB controller driver built in or loadable.
2. Confirm the vulnerable driver can be initialized, reprobed, or otherwise triggered on the target hardware or emulated platform.
3. Trigger the omap2430_probe() path so the driver releases the device tree node reference before its final use.
4. Attempt to reclaim or influence the freed kernel memory before the stale pointer is accessed.
5. Leverage the resulting memory corruption to crash the kernel or, if exploit primitives are reliable, attempt local privilege escalation.

How to detect it

Look for evidence of prior local exploitation or crash attempts in kernel and system logs. Relevant sources include dmesg output, journald, /var/log/kern.log, /var/log/messages, /var/log/syslog, crash dumps, kdump/vmcore artifacts, audit logs for module loading, and endpoint telemetry showing unusual local activity preceding kernel faults. Search for kernel warnings, oopses, panics, KASAN reports, slab corruption, page faults, or general protection faults involving omap2430_probe, musb, omap2430, device tree node handling, or of_node_put. Also review module load/unload events for musb-related modules, especially if performed by unexpected users or processes. There are no known public exploit-specific indicators, named threat actors, or ransomware use reported for this vulnerability, so detection should focus on behavioral evidence of driver probing abuse and kernel memory corruption.

• omap2430_probe
• of_node_put
• musb-omap2430
• omap2430
• KASAN: use-after-free
• BUG: KASAN: use-after-free
• general protection fault
• kernel NULL pointer dereference
• Unable to handle kernel paging request
• slab-out-of-bounds
• kernel BUG at
• Oops:
• Kernel panic
• /var/log/kern.log
• /var/log/messages
• /var/log/syslog
• /proc/config.gz
• CONFIG_USB_MUSB_OMAP2PLUS
• musb_hdrc
• modprobe musb
• modprobe musb_hdrc

What your security team should do

• Prioritize patching affected embedded, appliance, mobile/SoC, or hardware-specific Linux systems where the OMAP2430 MUSB driver is enabled or required.
• Inventory kernels and kernel configurations to determine whether CONFIG_USB_MUSB_OMAP2PLUS or equivalent OMAP2430 MUSB support is built in or available as a module.
• If patching is delayed, disable or blacklist the affected driver where operationally safe and enforce controls that prevent untrusted users from loading kernel modules.
• Monitor kernel logs for crashes, warnings, or use-after-free reports involving musb, omap2430, of_node_put, KASAN, slab, or device tree probe activity.
• Track vendor advisories for exact fixed kernel package versions because fixed_versions were not provided in the input.
• Treat exploitation likelihood as currently low due to low EPSS, no KEV listing, and no reported public exploit maturity, but maintain urgency for exposed systems because kernel exploitation impact is high.