CVE-2026-97484 in Linux
Summary
by MITRE • 09/24/2026
In the Linux kernel, the following vulnerability has been resolved:
usbip: vhci_hcd: fix NULL deref in status_show_vhci
platform_get_drvdata() can return NULL if a VHCI host controller's probe failed (e.g. due to USB bus number exhaustion). status_show_vhci() checked for a NULL pdev but not for a NULL hcd returned by platform_get_drvdata(). Passing NULL to hcd_to_vhci_hcd() does not return NULL - it returns a pointer offset of 0x260, causing a NULL pointer dereference when that value is subsequently dereferenced.
Add a NULL check on hcd before calling hcd_to_vhci_hcd(). Move status_show_not_ready() above status_show_vhci() to make it callable from the new error path without a forward declaration.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/24/2026
The Linux kernel vulnerability identified in the usbip subsystem involves a critical null pointer dereference within the vhci_hcd driver, specifically triggered during the execution of the status_show_vhci function. This issue arises when platform_get_drvdata returns NULL due to a failure in the probe phase of a VHCI host controller initialization. Common causes for such probe failures include resource exhaustion scenarios, most notably USB bus number depletion, where the system cannot allocate unique identifiers required for device enumeration. While the existing code correctly verifies that the platform_device pointer is valid before proceeding, it fails to validate the return value from platform_get_drvdata, which retrieves driver-specific data associated with the device. When this retrieval fails and returns NULL, subsequent operations assume a valid structure exists in memory at that address.
The technical flaw centers on the improper handling of the host controller descriptor obtained via platform_get_drvdata. The function hcd_to_vhci_hcd is designed to convert a pointer to an usb_host_controller structure into a vhci_hcd structure by applying a fixed offset, specifically 0x260 bytes from the base address. When passed NULL as input, this macro or inline function does not return NULL but instead calculates and returns a memory address at offset 0x260 from zero. This effectively creates an invalid pointer that points to unmapped kernel space or protected regions near the beginning of the virtual address space. Any subsequent attempt to dereference fields within this calculated structure results in a page fault, leading to a kernel panic or system crash. This behavior exemplifies a classic logic error where arithmetic operations on null pointers are not guarded against, assuming that pointer arithmetic will naturally yield NULL if the base is NULL, which is incorrect in C programming semantics and Linux kernel development practices.
From an operational impact perspective, this vulnerability allows for local denial of service attacks by any user with access to the relevant sysfs entries or interfaces exposed by the usbip driver. An attacker who can trigger conditions leading to USB bus number exhaustion, such as creating a large number of virtual USB devices rapidly, could force the probe function to fail repeatedly. Once the system reaches this state and an attempt is made to read status information through the affected interface, the kernel will crash due to the null pointer dereference at offset 0x260. This disrupts availability for all users on the host system and potentially compromises stability in environments relying heavily on USB over IP connectivity solutions provided by usbip. The vulnerability falls under CWE-476, which describes a NULL Pointer Dereference, indicating that the software performs an operation using a pointer that evaluates to null without proper validation.
Mitigation strategies involve both immediate patching of the kernel source and broader architectural improvements in error handling practices within device drivers. The primary fix requires adding explicit null checks on the host controller structure returned by platform_get_drvdata before invoking hcd_to_vhci_hcd. If the driver data is missing, indicating a failed probe or uninitialized state, the function should gracefully handle this condition rather than proceeding with invalid memory access. Additionally, refactoring the code to move status_show_not_ready above status_show_vhci allows for cleaner error path management without requiring forward declarations, improving maintainability and reducing cognitive load for developers reviewing the driver logic. Security teams should ensure that kernel updates incorporating these fixes are applied promptly. Furthermore, adopting static analysis tools capable of detecting null pointer dereferences after arithmetic operations can help identify similar latent defects in other parts of the codebase before they reach production environments. This incident also highlights the importance of adhering to ATT&CK techniques related to system availability disruption through resource exhaustion and exploitation of software vulnerabilities for denial of service effects.