CVE-2026-31759

What it actually does

This is a Linux kernel memory-corruption flaw in the USB ULPI registration error path. If device_register() fails during ulpi_register_interface(), the kernel calls put_device(), which triggers the ULPI device release callback and frees the ULPI structure. The vulnerable error path then frees the same structure again, creating a double-free condition. Because this occurs in kernel memory, successful exploitation could potentially lead to kernel crash, memory corruption, privilege escalation, or arbitrary kernel-code execution, although exploitation requires local access with the ability to trigger the affected USB/ULPI device-registration path. The CVSS vector indicates local attack, low complexity, low privileges required, no user interaction, and high confidentiality, integrity, and availability impact.

Why it matters to the business

The main operational risk is that a local user or compromised low-privileged process on an affected Linux system could potentially crash the host or escalate privileges to full kernel-level control. This is most relevant for systems where untrusted users, containers, device-management software, or workloads can influence USB device enumeration or kernel driver paths. Current public exploitation indicators are limited: the vulnerability is not listed in CISA KEV, is not associated with ransomware use, has no known mature exploit, and has a very low and stable EPSS score of 0.00129 over the last 30 days. Even so, because kernel privilege-escalation bugs can become valuable once exploit techniques are developed, organizations should remediate through normal kernel patching cycles, prioritizing multi-user Linux servers, developer workstations, edge devices, and systems with physical or virtual USB exposure.

How an attack unfolds

An attacker first needs local code execution with low privileges on a vulnerable Linux system. They then need to reach the affected USB ULPI registration path and cause device_register() to fail at the right point in ulpi_register_interface(). On a vulnerable kernel, the failure path calls put_device(), which invokes the device release routine and frees the ULPI object. The same error path then incorrectly calls kfree() on that already-freed object. In the simplest case, this causes a kernel crash and denial of service. With careful heap grooming, timing, and control over nearby kernel allocations, an attacker may attempt to turn the double free into use-after-free-style memory corruption, potentially corrupting kernel objects and escalating from a low-privileged local account to kernel-level execution. There are no public signs in the provided data that this has been weaponized in the wild, and no named threat actors are associated with it.

How to fix it

Apply a Linux kernel update that includes the upstream fix for the USB ULPI double-free bug in ulpi_register_interface(). No exact fixed package versions were provided, so remediation should be based on the relevant distribution or vendor kernel advisory for CVE-2026-31759. Reboot systems after installing the fixed kernel and confirm the running kernel, not only the installed package, has been updated. Where immediate patching is not possible, reduce exposure by limiting local shell access, restricting untrusted workloads, disabling or avoiding unnecessary USB/ULPI-related hardware paths where operationally feasible, enforcing least privilege, and using kernel hardening features such as lockdown mode, module-loading restrictions, SELinux/AppArmor, and container isolation. Mitigations should not be treated as equivalent to patching because the flaw is in kernel memory-management logic.

How to confirm the fix worked

Confirm exposure by inventorying Linux systems and comparing the running kernel version and vendor patch level against the distribution advisory that fixes CVE-2026-31759. Validate with uname -a, package-manager queries, and vendor security metadata, ensuring the host has been rebooted into the patched kernel. For source-based or custom kernels, verify that the ULPI registration error path no longer frees the ULPI object after put_device() has transferred cleanup to ulpi_dev_release(). Where kernel debug tooling is available, review the relevant source or build changelog for the USB ULPI double-free fix. Confirm that no affected kernel remains booted after patch deployment. Also review kernel logs for historical signs of crashes or memory-corruption reports involving ULPI, KASAN, SLUB, double free, or device registration failures.

Typical attack path

1. Obtain local low-privileged execution on an affected Linux system.
2. Identify whether the running kernel includes the vulnerable USB ULPI error path.
3. Trigger USB/ULPI interface registration in a way that causes device_register() to fail.
4. Force the vulnerable cleanup path in ulpi_register_interface() to call put_device() and then free the same ULPI allocation again.
5. Use the double free to crash the kernel, or attempt heap manipulation to corrupt kernel memory.
6. If exploitation is reliable, escalate privileges or execute code in kernel context.

How to detect it

To assess whether this was already exploited, review kernel logs, system journals, crash dumps, and endpoint telemetry for evidence of kernel memory corruption around USB ULPI device registration. Useful sources include /var/log/kern.log, /var/log/messages, journalctl -k output, dmesg history, kdump/vmcore artifacts, crash reports, and EDR telemetry showing local processes interacting with USB or device-management paths shortly before a kernel panic. Look for KASAN, SLUB, or general kernel BUG messages referencing double free, kfree(), put_device(), ulpi_register_interface(), ulpi_register(), ulpi_dev_release(), device_register(), or USB ULPI. Because exploitation is local and may leave only crash artifacts, absence of logs does not prove absence of exploitation, especially if logs are volatile or overwritten after reboot. There are no known campaign-specific indicators, threat-actor signatures, ransomware links, or public exploit artifacts in the provided intelligence.

• BUG: KASAN: double-free
• KASAN: double-free
• double free
• kernel BUG at mm/slub.c
• kernel BUG at mm/slab.c
• WARNING: CPU
• general protection fault
• Oops:
• RIP: .*ulpi_register_interface
• ulpi_register_interface
• ulpi_register
• ulpi_dev_release
• device_register
• put_device
• kfree
• usb: ulpi
• ULPI
• /var/log/kern.log
• /var/log/messages
• journalctl -k
• /proc/vmcore

What your security team should do

• Patch affected Linux kernels through the appropriate vendor channel and reboot into the fixed kernel.
• Prioritize systems with local untrusted users, shared developer access, container workloads, physical USB exposure, edge/embedded deployments, or device-management functionality.
• Track vendor advisories because no exact fixed versions were provided in the input; map each Linux distribution and kernel branch to its fixed release.
• Hunt kernel logs for prior crashes or memory-corruption messages involving ULPI, double free, KASAN, SLUB, or device_register failures.
• Restrict local access and reduce unnecessary USB/device-management capabilities on systems that cannot be patched quickly.
• Ensure kernel crash dump collection, audit logging, and endpoint telemetry are enabled on high-value Linux systems to support post-incident analysis.
• Monitor for future exploit publication despite the currently low EPSS score, no KEV listing, and no known ransomware association.