CVE-2024-26919

What it actually does

A mismatch in debugfs directory naming during ulpi_unregister_interface leaves the per-device debugfs root directory in place instead of removing it, which blocks subsequent device probe attempts including deferred ones.

Why it matters to the business

USB device initialization can repeatedly fail on affected Linux systems after interface unregistration events, causing operational interruptions for hardware that depends on ULPI-based USB controllers.

How an attack unfolds

An attacker with the ability to trigger repeated registration and unregistration of ULPI devices can cause the debugfs directory to accumulate, resulting in persistent probe failures that degrade or deny USB functionality without requiring code execution.

How to fix it

Apply the upstream fix present in commit d31b886ed6a5095214062ee4fb55037eb930adb6 or later kernels that contain the corrected directory naming logic in drivers/usb/ulpi/ulpi.c.

How to confirm the fix worked

Confirm the running kernel contains commit d31b886ed6a5095214062ee4fb55037eb930adb6 or verify that debugfs directories are correctly removed on ulpi_unregister_interface by inspecting /sys/kernel/debug after device removal.

Typical attack path

1. Gain ability to attach or detach ULPI USB devices on the target system
2. Trigger ulpi_register_interface followed by ulpi_unregister_interface
3. Observe that the debugfs directory named after the ulpi device persists
4. Cause subsequent probe attempts to fail due to the stale directory

How to detect it

Review kernel logs for repeated ULPI probe failures and inspect debugfs for orphaned directories named after ULPI devices that should have been removed on unregistration.

What your security team should do

• Patch all affected Linux kernel versions to include the referenced commit
• Monitor USB device probe success rates in production environments
• Test ULPI device hot-plug and unregistration scenarios after applying updates