CVE-2026-46109

What it actually does

This is a Linux kernel memory leak in the USB ULPI registration error path. When ULPI device registration fails before device_register() is called, specifically through ulpi_of_register() or ulpi_read_id() failure paths, the allocated ulpi object is not freed. A local attacker who can repeatedly trigger these failure paths may cause unreclaimed kernel memory growth, potentially exhausting memory and degrading or crashing the system. The impact is availability-only; it does not directly provide code execution, privilege escalation, or data disclosure.

Why it matters to the business

Affected Linux systems may become unstable or unavailable if kernel memory is repeatedly leaked, causing service disruption, device malfunction, or reboot requirements. The practical risk is highest for systems that expose or rely on USB ULPI hardware paths, embedded Linux platforms, appliances, and environments where local users or workloads can influence USB/device probing behavior. This issue is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, has very low EPSS, and has no known mature public exploit, so remediation can usually follow normal kernel patch cycles unless exposed systems are reliability-critical.

How an attack unfolds

An attacker first needs local access with enough ability to influence USB/ULPI device registration or related kernel probing behavior. They then cause ULPI registration attempts to fail before the kernel reaches device_register(), for example by repeatedly triggering conditions that make ulpi_of_register() or ulpi_read_id() return errors. Each failed attempt leaks a small kernel allocation instead of freeing it. By repeating the trigger many times, the attacker can gradually consume kernel memory. If memory pressure becomes severe enough, the system may experience degraded performance, failed allocations, out-of-memory events, service crashes, or a kernel panic/reboot. Exploitation is constrained by local access requirements and hardware/subsystem reachability.

How to fix it

Upgrade to a Linux kernel version or distribution kernel package that includes the upstream fix for the USB ULPI ulpi_register() error-path memory leak. No exact fixed package versions were provided, so use the relevant Linux distribution, hardware vendor, or appliance vendor advisory to identify the corrected kernel build. Where immediate patching is not possible, reduce exposure by restricting local user access, limiting untrusted workloads, disabling unnecessary USB/ULPI-related modules or hardware paths where operationally safe, preventing unauthorized kernel module loading, and restricting access to device-management interfaces such as udev-triggering workflows, configfs/debugfs interfaces, or privileged container configurations that can influence device probing.

How to confirm the fix worked

Confirm the running kernel includes the backported patch that frees the ulpi allocation on ulpi_of_register() and ulpi_read_id() error paths. Validate by checking the installed kernel changelog or vendor advisory for the USB ULPI memory leak fix, then rebooting into the corrected kernel and confirming the active kernel version. In staging or lab systems with representative hardware, exercise ULPI registration failure paths while monitoring kernel memory usage and kmemleak output; memory should not grow without bound after repeated failures. Also verify mitigations by confirming unnecessary USB/ULPI modules are not loaded, local users cannot load kernel modules, and privileged device-management interfaces are restricted.

Typical attack path

1. Obtain local access to a Linux system running an affected kernel.
2. Identify whether USB ULPI-related functionality, drivers, modules, or device-probing paths are reachable.
3. Trigger ULPI registration attempts that fail before device_register(), such as failure paths involving ulpi_of_register() or ulpi_read_id().
4. Repeat the failure condition many times to leak kernel memory incrementally.
5. Wait for cumulative memory pressure to cause service degradation, allocation failures, OOM activity, kernel instability, or system reboot.

How to detect it

To determine whether this was already exploited or triggered, review historical kernel and system logs for repeated USB/ULPI registration or probe failures followed by increasing memory pressure. Useful sources include dmesg, journalctl kernel logs, /var/log/kern.log, /var/log/messages, syslog, auditd logs for module loading or device-management activity, udev logs, container runtime logs for privileged device access, and monitoring data for kernel memory, slab growth, OOM events, swap exhaustion, and unexpected reboots. Look for repeated failures referencing ULPI symbols or USB PHY probing, especially when correlated with local logins, module insertion/removal, device rebinds, udev-trigger activity, or privileged container starts. Because this flaw is a memory leak rather than a payload-based compromise, there may be no durable file, process, registry, or network IOC; evidence is most likely behavioral and log-based.

• ulpi_register
• ulpi_of_register
• ulpi_read_id
• usb: ulpi
• ULPI
• Out of memory
• oom-killer
• Killed process
• kernel: Out of memory
• kmemleak
• unreferenced object
• modprobe ulpi
• modprobe ulpi_viewport
• /sys/kernel/debug/kmemleak
• /var/log/kern.log
• /var/log/messages

What your security team should do

• Prioritize patching reliability-critical Linux systems, embedded platforms, appliances, and systems that use USB ULPI hardware or expose device-probing paths to local users or workloads.
• Track vendor kernel advisories and deploy the first available fixed kernel package or appliance firmware containing the upstream USB ULPI fix.
• Because exploitation requires local access and there is no known KEV or public exploit maturity, handle most general-purpose servers through the standard kernel maintenance window unless service availability risk is high.
• Restrict local privilege boundaries: prevent untrusted users or containers from loading kernel modules, accessing privileged device-management interfaces, or manipulating USB/gadget/debug interfaces.
• Monitor affected systems for unexplained kernel memory growth, OOM killer activity, repeated USB/ULPI probe failures, and reboots until patched.
• If suspicious activity is observed, preserve kernel logs, audit logs, module-load history, and memory-pressure telemetry before rebooting where feasible.