CVE-2026-53331: Linux Kernel SlimBus Deadlock Vulnerability

Technical summary

The vulnerability exists in drivers/slimbus/qcom-ngd-ctrl.c within the qcom_slim_ngd_ssr_pdr_notify() function. During SSR/PDR down notification, the function acquires ctrl->tx_lock to synchronize with active DMA transfers. However, the code then calls qcom_slim_ngd_down(), which eventually invokes slim_report_absent() in the core SlimBus driver—a function that requires ctrl->lock. Throughout the codebase, these two locks are typically acquired in the opposite order (ctrl->lock first, then tx_lock), creating a classic ABBA deadlock scenario. The lockdep verification system detects this potential circular wait condition. The fix removes the unnecessary tx_lock acquisition in qcom_slim_ngd_ssr_pdr_notify(), since the transmit lock's stated purpose—preventing calls to qcom_slim_ngd_exit_dma() during active DMA transactions—is already naturally prevented by the fact that DMA transactions complete within single qcom_slim_ngd_xfer_msg() calls before the controller teardown sequence begins.

Business impact

This vulnerability can cause kernel panics or system hangs during subsystem or processor domain restart events, which are critical operational scenarios particularly in mobile and embedded systems using Qualcomm platforms. An affected system could become unresponsive during firmware update procedures, device resets, or modem restarts—common maintenance operations. The impact is availability-focused; there is no data confidentiality or integrity breach. For organizations operating infrastructure with affected Qualcomm-based devices, remediation is important to maintain system stability during normal lifecycle operations, though the triggering conditions are relatively specific to restart events rather than continuous runtime exposure.

Affected systems

Linux kernel installations containing the affected Qualcomm SlimBus NGD (Next Generation Device) controller driver code. This primarily affects mobile devices, IoT devices, and embedded systems using Qualcomm chipsets where the qcom-ngd-ctrl driver is compiled in. The vulnerability is present in kernel versions containing the affected code path; however, the specific kernel versions have not been enumerated in the provided vulnerability data. Systems must be verified against the Linux kernel source repository and relevant vendor advisories to determine exact affected ranges.

Exploitability

Exploitability is low to moderate in practical terms. The vulnerability is triggered during legitimate system operations (SSR/PDR events), not via direct user interaction or network attack. An attacker cannot remotely trigger a deadlock; it occurs only when the system naturally undergoes restart procedures. A local user with sufficient privilege to trigger or monitor system restart events could potentially observe or influence the timing of the deadlock condition, but exploitation requires system-level access and the specific hardware/firmware restart conditions. The vulnerability is more accurately characterized as a reliability bug that impacts availability under normal operational circumstances rather than a traditional security exploit vector.

Remediation

Apply kernel updates that include the fix for CVE-2026-53331. The resolution involves removing the unnecessary tx_lock acquisition in the qcom_slim_ngd_ssr_pdr_notify() function. Organizations should verify the exact kernel versions containing the fix through the Linux kernel source repository and coordinate updates with their device manufacturer, as kernel updates may require testing and coordination with system-specific configurations. No workaround is available; patching is the only remediation path.

Patch guidance

Identify your current Linux kernel version using 'uname -r' or equivalent commands. Consult the Linux kernel source repository at kernel.org and your device manufacturer's security advisories for kernel versions that include the fix for drivers/slimbus/qcom-ngd-ctrl.c. Test any kernel updates in a non-production environment first to ensure compatibility with dependent systems and services. Because this fix is in the SlimBus controller driver, it is most critical for systems that actively use SlimBus for audio or other device communication—typically mobile and embedded platforms. Verify against vendor advisory documentation for exact patch versions and timelines applicable to your environment.

Detection guidance

Monitor system logs for lockdep warnings or deadlock messages mentioning 'ctrl->lock' and 'ctrl->tx_lock' in the context of qcom_slim_ngd or SlimBus code. Kernel panic logs or hung task warnings during SSR/PDR events may indicate this condition. Use CONFIG_PROVE_LOCKING kernel configuration to enable lockdep verification, which will detect the lock ordering violation at runtime. Test kernel updates in staging environments with SSR/PDR simulation to confirm the issue is resolved before full deployment.

Why prioritize this

While this vulnerability carries a MEDIUM CVSS score (5.5), it should be prioritized based on your system environment. Prioritize immediately if your infrastructure relies on Qualcomm-based mobile or embedded devices that undergo regular restart cycles or firmware updates, as deadlocks during these operations disrupt availability. For server-centric or non-Qualcomm deployments, this vulnerability is lower priority. The fix is surgical (removal of problematic lock acquisition) and low-risk, making patching feasible once updated kernels are available from your vendor.

Risk score, explained

The CVSS 3.1 score of 5.5 (MEDIUM) reflects an attack vector of local only (AV:L), low complexity (AC:L), low privilege requirements (PR:L), no user interaction (UI:N), unchanged scope (S:U), and high availability impact (A:H). The scoring appropriately captures that this is a local denial-of-service vulnerability with no confidentiality or integrity impact. The score does not account for the relatively narrow triggering conditions (SSR/PDR events), which in practice limit exploitability compared to vulnerabilities triggered during normal operation, but the availability impact during those events is complete.

Frequently asked questions