In mid-2024, a serious bug (CVE-2024-45006) was reported and fixed in the Linux kernel's xHCI USB controller driver, specifically affecting some Intel Panther Point host controllers. This vulnerability could lead to Linux kernel crashes when full-speed USB devices are re-enumerated after certain failures. The root cause: a NULL pointer dereference due to incorrectly set bandwidth management structures.

This post will break down the bug in plain language, how to recognize it, example log output, the code involved, who is affected, and links to further reading.

What Is Panther Point and the xHCI Bug?

Panther Point is an Intel chipset family using the xHCI controller for USB 3.. The xHCI Linux driver (in drivers/usb/host/xhci.c) has special code to track bandwidth use in these chipsets—unlike other platforms, which do so in hardware. When a full-speed device fails during enumeration, then tries again, this path can trigger the driver to use uninitialized data.

If that fails (for example, device not responding), the kernel may retry.

- On full-speed devices (USB 1.1, like keyboards), the endpoint maximum packet size might need reconfiguration. The kernel resets the internal USB endpoint (via usb_ep_reinit()), which calls xhci_configure_endpoint() for the host controller.

It creates a new struct with pointers (bandwidth management tables) uninitialized.

3. Upon retry, when xhci_configure_endpoint() is run (via reinit), it tries to check/reserve bandwidth using NULL pointers (leading to a kernel crash).

Here’s what you’d see in dmesg or logs

[46710.713538] usb 3-1: new full-speed USB device number 5 using xhci_hcd
[46710.713699] usb 3-1: Device not responding to setup address.
[46710.917684] usb 3-1: Device not responding to setup address.
[46711.125536] usb 3-1: device not accepting address 5, error -71
[46711.125594] BUG: kernel NULL pointer dereference, address: 0000000000000008
[46711.125600] #PF: supervisor read access in kernel mode
[46711.125606] PGD  P4D 
[46711.125610] Oops: Oops: 000 [#1] PREEMPT SMP PTI
[46711.125615] CPU: 1 PID: 25760 Comm: kworker/1:2 Not tainted 6.10.3_2 #1

You can see the kernel Oops from a NULL pointer (address x0000000000000008)!

Excerpt showing the crux of the issue (from drivers/usb/host/xhci.c)

// In xhci_configure_endpoint()
if (xhci->quirks & XHCI_EP_BANDWIDTH_QUIRK) {
    // Panther Point: software tracks per-device bandwidth
    // ... try to access bandwidth table ...
    struct xhci_virt_device *dev = xhci->devs[udev->slot_id];
    struct xhci_bw_info *bw_table = dev->bw_table;
    int ep_index = ...;
    // CRITICAL: bw_table might be NULL here!
    bw_table[ep_index].some_value = ... ; // <-- crash!
}

The bug: bw_table is NULL if it wasn't set up after a failed address command.

The fix for CVE-2024-45006 ensures that

- bw_table is always allocated and initialized when the device structure is re-created after a failure.
- The bandwidth check is skipped if only endpoint (the default control endpoint) is being configured, as no bandwidth change is needed.

Patch reference

Commit: xhci: Fix Panther point NULL pointer deref at full-speed re-enumeration

Before the fix:
You get a kernel crash after address command fails and retries.
After the fix:
No crash, enumeration recovers, no NULL dereference.

Does This Allow Remote Exploitation?

Not in the classic data-leak or code execution sense. This is a Denial of Service (kernel panic/Oops) that could be triggered by a malfunctioning or malicious USB device that purposely fails address phase, causing repeated re-enumeration, perpetually crashing the system.

Exploit Example (Proof-of-Concept)

If you have access to such a device, or can use a programmable USB "Fuzzing" device (like Facedancer), you could perform the following:

Here’s a simplified pseudo-Python case (actual implementation device-dependent)

# Pseudocode: Not real code

while True:
    # Wait for device connect
    on_usb_connect():
        # Do NOT answer "Set Address" request
        pass
    # Host will retry
    # If the kernel is vulnerable and using Panther Point, a crash occurs
    # after a few cycles of failed enumeration

Avoid connecting untrusted or suspicious USB devices to machines with Panther Point xHCI.

- Watch for xhci_hcd-related kernel errors or OOPS in dmesg/logs as an indicator.

- Linux Commit for CVE-2024-45006
- LKML Patch Discussion
- xHCI Linux Driver Source (xhci.c)
- USB Enumeration Explanation (USB Made Simple)

Final Thoughts

CVE-2024-45006 offers a clean example of how hardware-specific quirks and subtle resource management can open up system stability issues—especially in code that deeply interfaces with hardware, such as USB host controllers.

If you use Linux and have an older Intel-based PC, update your kernel to stay safe. And as always—don't plug in untrusted USB devices!


*Exclusive coverage, written simply for the wider Linux user community. Please share if you found this explanation helpful!*

Timeline

Published on: 09/04/2024 20:15:08 UTC
Last modified on: 09/06/2024 16:26:52 UTC