CVE-2026-90280 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
phy: qcom: qmp-usb: Fix possible NULL-deref on early runtime suspend
There is a small window where the runtime suspend callback may run after pm_runtime_enable() and before pm_runtime_forbid(). In this case, a crash occurs because runtime suspend/resume dereferences qmp->phy pointer, which is not yet initialized: `if (!qmp->phy->init_count) {`
This can also happen if user re-enables runtime-pm via the sysfs attribute before qmp phy is initialized.
Similarly to other qcom phy drivers, introduce a qmp->phy_initialized variable that can be used to avoid relying on the possibly uninitialized phy pointer.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/17/2026
The Linux kernel driver for Qualcomm USB PHY interfaces contains a race condition vulnerability located within its runtime power management logic. This flaw arises from an improper synchronization window during device initialization and suspension sequences. Specifically, there exists a brief interval between the invocation of pm_runtime_enable() and pm_runtime_forbid(). During this period, if the system attempts to suspend the device via runtime PM callbacks, the driver may execute code that accesses hardware-specific structures before they are fully initialized by the probe function. This timing issue is not limited to standard boot sequences but can also be triggered artificially through user-space interaction, such as re-enabling runtime power management via sysfs attributes prior to the completion of PHY initialization routines.
The technical root cause involves a NULL pointer dereference within the qmp_usb_runtime_suspend callback function. The code attempts to access the init_count field of the phy structure using the expression if (!qmp->phy->init_count). However, at this specific point in execution, the qmp->phy pointer has not yet been assigned or initialized by the driver's probe routine. Consequently, accessing a member through an uninitialized or NULL pointer results in a kernel panic or system crash. This represents a classic use-before-initialization flaw where the control flow allows access to resources that are expected to be valid but are currently null due to asynchronous execution timing between power management subsystems and hardware initialization drivers.
From a security perspective, this vulnerability is classified under CWE-476, which denotes NULL Pointer Dereference. The impact of exploiting this condition includes denial of service against the host system or specific USB controller functionality. While local physical access or root privileges are typically required to trigger sysfs-based race conditions, automated tools or scripts that manipulate power states rapidly could potentially induce instability in embedded systems relying on Qualcomm hardware. Furthermore, if such a crash occurs during critical boot processes or hot-plug events, it can lead to data corruption or system unavailability without requiring external network access, making the attack vector primarily local and privilege-dependent rather than remote.
To mitigate this vulnerability, developers have implemented a defensive programming pattern by introducing a dedicated qmp->phy_initialized boolean flag within the driver structure. This variable serves as an explicit guard that checks whether the PHY hardware has been fully probed and initialized before allowing any runtime suspend or resume operations to proceed. By checking this status bit instead of relying on pointer validity alone, the driver ensures that power management callbacks safely return early if initialization is incomplete. This approach aligns with ATT&CK technique T1053, specifically regarding scheduled tasks or cron jobs that might manipulate system states, although in this context it primarily addresses internal kernel race conditions rather than external persistence mechanisms. The fix effectively closes the timing window by decoupling power state transitions from hardware readiness checks until initialization is confirmed complete.