CVE-2026-53331

What it actually does

This is a Linux kernel race-condition/deadlock flaw in the Qualcomm SLIMbus NGD controller driver. During subsystem restart or protection-domain-restart down notifications, the driver takes tx_lock and then calls paths that acquire the SLIMbus controller lock, while other code paths acquire those locks in the reverse order. This ABBA lock ordering issue can deadlock kernel execution on affected Qualcomm platforms, potentially hanging SLIMbus-related device handling and causing system instability or denial of service. It does not indicate memory corruption, privilege escalation, or remote code execution based on the available description.

Why it matters to the business

Affected Linux-based systems using the Qualcomm SLIMbus NGD controller can become unstable or hang during subsystem restart, device teardown, or related hardware recovery events. In operational terms, this can cause device freezes, audio/modem-related service disruption, watchdog resets, or unplanned reboots. The vulnerability is not in CISA KEV, has very low EPSS, and has no known public exploit maturity, so urgency is lower than actively exploited kernel vulnerabilities, but it should still be remediated through normal kernel maintenance because kernel deadlocks can affect availability.

How an attack unfolds

An attacker would need a way to influence or repeatedly trigger the relevant Qualcomm SLIMbus subsystem restart/protection-domain-restart down-notification path while SLIMbus message transfer or controller teardown paths are active. If the timing aligns, one execution path holds the transmit lock and waits for the controller lock, while another path holds the controller lock and waits for the transmit lock. Neither path can proceed, resulting in a kernel deadlock. In realistic scenarios this is most likely to manifest as a local denial-of-service condition on affected Qualcomm-based systems rather than as remote compromise. There is currently no indication from the supplied data that this flaw is being exploited by named threat actors or ransomware campaigns.

How to fix it

Apply a Linux kernel update from the distribution, device vendor, BSP provider, or upstream stable tree that includes the fix for the Qualcomm SLIMbus NGD controller lock-ordering issue. The fix removes the unnecessary tx_lock acquisition in qcom_slim_ngd_ssr_pdr_notify(), avoiding the ABBA deadlock with the SLIMbus controller lock. No exact fixed package versions were provided, so prioritize vendor advisories for kernels used on Qualcomm-based platforms. If immediate patching is not possible, reduce exposure by limiting untrusted local access, disabling unnecessary SLIMbus-dependent hardware features where operationally acceptable, and monitoring for repeated subsystem restart, hung-task, or watchdog-reset events. Kernel mitigations generally cannot fully prevent this class of driver deadlock without the code fix.

How to confirm the fix worked

Confirm that the running kernel build contains the vendor or upstream patch that changes drivers/slimbus/qcom-ngd-ctrl.c so qcom_slim_ngd_ssr_pdr_notify() no longer takes ctrl->tx_lock before calling the SLIMbus teardown/reporting path. Validate by checking the installed kernel package changelog, vendor advisory, source diff, or build provenance. On test hardware, exercise subsystem restart/protection-domain-restart and SLIMbus device teardown scenarios while monitoring dmesg/journal logs for lockdep warnings, hung tasks, soft lockups, or watchdog resets. A remediated system should not produce ABBA lockdep reports involving &ctrl->tx_lock and &ctrl->lock in the qcom-ngd-ctrl SLIMbus path.

Typical attack path

1. Identify a Linux system running an affected kernel with the Qualcomm SLIMbus NGD controller driver enabled and relevant Qualcomm hardware present.
2. Obtain local ability, device-control capability, or another mechanism to cause repeated subsystem restart or protection-domain-restart events affecting the SLIMbus controller.
3. Create timing pressure by causing SLIMbus activity, device removal, or DMA/message-transfer activity while the down-notification path executes.
4. Trigger the inconsistent lock acquisition order between tx_lock and the SLIMbus controller lock.
5. Cause a kernel deadlock, leading to hung tasks, device-service disruption, watchdog reset, or system reboot.

How to detect it

This flaw does not produce network indicators and is primarily detectable through host kernel telemetry. Review dmesg, journalctl, /var/log/kern.log, /var/log/messages, pstore/ramoops, crash dumps, watchdog logs, and device-management logs for lockdep reports, hung tasks, soft lockups, or watchdog resets involving the Qualcomm SLIMbus NGD controller. Look for evidence of an ABBA lock dependency between ctrl->tx_lock and ctrl->lock, especially stack traces containing qcom_slim_ngd_ssr_pdr_notify(), qcom_slim_ngd_down(), slim_report_absent(), qcom_slim_ngd_xfer_msg(), or the rprocctl task. To assess possible prior exploitation, correlate these kernel events with repeated subsystem restart/protection-domain-restart events, device reset activity, local user or application activity immediately before the hang, and unexpected reboots. Absence of these artifacts does not prove non-exploitation because a deadlock may leave limited logs if the system resets abruptly.

• qcom_slim_ngd_ssr_pdr_notify
• qcom_slim_ngd_down
• qcom_slim_ngd_exit_dma
• qcom_slim_ngd_xfer_msg
• slim_report_absent
• slim_qcom_ngd_ctrl
• drivers/slimbus/qcom-ngd-ctrl.c
• drivers/slimbus/core.c
• &ctrl->tx_lock
• &ctrl->lock
• Possible unsafe locking scenario
• trying to acquire lock:
• but task is already holding lock:
• which lock already depends on the new lock
• rprocctl/
• lockdep splat
• slimbus
• hung task
• soft lockup
• watchdog: BUG: soft lockup

What your security team should do

• Inventory Linux systems and embedded devices using Qualcomm-based kernels or board support packages where the SLIMbus NGD controller driver may be enabled.
• Track vendor kernel advisories and apply the first available fixed kernel or BSP update containing the qcom-ngd-ctrl lock-ordering fix.
• Prioritize remediation for systems where local users, apps, containers, or peripheral-management components can trigger subsystem restart, device reset, or hardware recovery events.
• Enable or review kernel logging for lockdep, hung task, soft lockup, watchdog, rproc, and SLIMbus-related errors on affected device classes.
• Investigate repeated SLIMbus, remoteproc, SSR/PDR, or watchdog-reset events as potential exploitation attempts or reliability failures until systems are patched.
• If patching is delayed, restrict untrusted local execution and unnecessary access to device-control interfaces that can influence subsystem restart or hardware recovery paths.