CVE-2025-71193 in Linux
Summary
by MITRE • 02/04/2026
In the Linux kernel, the following vulnerability has been resolved:
phy: qcom-qusb2: Fix NULL pointer dereference on early suspend
Enabling runtime PM before attaching the QPHY instance as driver data can lead to a NULL pointer dereference in runtime PM callbacks that expect valid driver data. There is a small window where the suspend callback may run after PM runtime enabling and before runtime forbid. This causes a sporadic crash during boot:
``` Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a1 [...]
CPU: 0 UID: 0 PID: 11 Comm: kworker/0:1 Not tainted 6.16.7+ #116 PREEMPT Workqueue: pm pm_runtime_work pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : qusb2_phy_runtime_suspend+0x14/0x1e0 [phy_qcom_qusb2]
lr : pm_generic_runtime_suspend+0x2c/0x44 [...]
```
Attach the QPHY instance as driver data before enabling runtime PM to prevent NULL pointer dereference in runtime PM callbacks.
Reorder pm_runtime_enable() and pm_runtime_forbid() to prevent a short window where an unnecessary runtime suspend can occur.
Use the devres-managed version to ensure PM runtime is symmetrically disabled during driver removal for proper cleanup.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 04/30/2026
The vulnerability CVE-2025-71193 represents a critical NULL pointer dereference issue within the Qualcomm QUSB2 PHY driver of the Linux kernel, specifically affecting the phy_qcom_qusb2 module. This flaw manifests during the early boot process when runtime power management is enabled prematurely before the QPHY instance is properly attached as driver data, creating a temporal window where runtime PM callbacks can execute with invalid or null driver data references. The issue stems from improper ordering of initialization sequences where pm_runtime_enable() is called before the driver data attachment occurs, leading to a race condition that can cause kernel crashes during system boot operations.
The technical implementation of this vulnerability involves a classic race condition scenario where the kernel's power management subsystem attempts to execute runtime suspend callbacks before the driver has fully initialized its data structures. The crash occurs at virtual address 0x00000000000000a1, which corresponds to a NULL pointer dereference in the qusb2_phy_runtime_suspend function, indicating that the driver data structure expected by the runtime PM callbacks is not yet available. This pattern aligns with CWE-476 which specifically addresses NULL pointer dereferences, and the issue demonstrates how improper initialization sequencing can lead to kernel-level instability. The problem is particularly insidious because it occurs sporadically during boot, making it difficult to reproduce and debug consistently.
The operational impact of this vulnerability extends beyond simple system crashes to potentially compromising system stability and reliability during critical boot phases. Systems utilizing Qualcomm QUSB2 PHY controllers, particularly those in mobile devices, embedded systems, and automotive applications, may experience unpredictable boot failures or system hangs. The sporadic nature of the crash means that affected systems might appear stable under normal conditions but could fail intermittently during boot, creating significant operational challenges for device manufacturers and system integrators. This vulnerability affects the fundamental power management infrastructure of the Linux kernel's PHY subsystem and could potentially impact other components that rely on similar initialization patterns.
The recommended mitigation strategy involves reordering the driver initialization sequence to ensure that the QPHY instance is attached as driver data before enabling runtime power management. This approach directly addresses the root cause by eliminating the temporal window where runtime PM callbacks could execute with null references. The fix implements proper synchronization between driver data attachment and power management enablement, using devres-managed functions to ensure symmetric cleanup during driver removal. This solution aligns with ATT&CK technique T1547.001 which involves privilege escalation through kernel-level modifications, and follows established best practices for kernel module development. The implementation also incorporates proper resource management patterns that prevent resource leaks and ensure consistent cleanup behavior, addressing potential memory corruption issues that could arise from improper driver lifecycle management.