CVE-2026-53332

What it actually does

This is a Linux kernel race condition in the Qualcomm SLIMbus NGD controller driver. During driver probe, subsystem-restart/PDR callbacks and interrupts could be registered before the NGD device and associated work structures were fully initialized. If a remote processor starts concurrently, is already running, or an interrupt arrives in that window, the callback can operate on uninitialized or NULL data, such as scheduling work on a NULL ngd_up_work pointer. The expected result is kernel warning, driver failure, boot instability, or denial of service on affected Qualcomm-based systems rather than data disclosure or privilege escalation based on the available description.

Why it matters to the business

Affected Qualcomm-based Linux devices may fail to boot reliably or may experience kernel warnings and subsystem instability during startup or remote processor lifecycle events. For organizations shipping or operating embedded, mobile, IoT, automotive, or appliance platforms using affected kernels, the main operational risk is device unavailability, failed upgrades, service disruption, increased support cases, and reduced fleet reliability. EPSS is very low, the issue is not listed in CISA KEV, and there is no reported exploit maturity, so urgency is primarily driven by exposure in production device fleets and reliability requirements rather than known active exploitation.

How an attack unfolds

An attacker would generally need a way to influence kernel timing around Qualcomm remote processor startup, subsystem restart, PDR registration, or relevant hardware interrupt delivery while the qcom-ngd-ctrl driver is probing. If the race is won, the kernel callback path executes before required NGD state has been initialized, causing operations on invalid or NULL structures. In practical terms, exploitation is most plausible as a local or device-adjacent denial-of-service condition on affected hardware, or as an accidental reliability failure during boot, resume, subsystem restart, or driver initialization. There is no public indication from the supplied data that this vulnerability is being exploited in the wild, used by ransomware, or weaponized for remote code execution.

How to fix it

Update to a kernel version or vendor BSP release that includes the upstream fix moving interrupt enablement and SSR/PDR callback registration until after the NGD device has been registered. If exact fixed package versions are not available from the operating system or device vendor, track the vendor advisory for the affected kernel branch and apply the next security or stability kernel update containing the qcom-ngd-ctrl SLIMbus fix. Where immediate patching is not possible, reduce exposure by avoiding unnecessary manual reloads of the affected driver, limiting local administrative access that can trigger remoteproc or driver lifecycle events, and testing boot/resume/subsystem restart stability before production deployment. Mitigations are limited because the flaw is in kernel driver initialization ordering.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel or vendor BSP includes the patch that registers SSR/PDR callbacks and enables interrupts only after NGD device registration. Validate affected hardware with repeated cold boots, warm reboots, suspend/resume cycles, and remoteproc restart scenarios while monitoring kernel logs for qcom_slim_ngd_ssr_pdr_notify, qcom_slim_ngd_ssr_notify, __queue_work warnings, or slim_qcom_ngd_ctrl stack traces. Confirm that no new kernel warnings, NULL workqueue scheduling events, driver probe failures, or boot hangs occur during these tests. Also verify package inventory and kernel build provenance against vendor release notes or source commits for the fixed SLIMbus qcom-ngd-ctrl behavior.

Typical attack path

1. Identify a Linux device using the Qualcomm SLIMbus NGD controller driver on affected hardware and kernel builds.
2. Obtain the ability to trigger or influence remote processor startup, subsystem restart, PDR notification timing, driver loading, reboot, resume, or relevant interrupt conditions.
3. Cause the remoteproc/PDR/SSR notification path or interrupt handler to run while the NGD driver probe has not completed initialization.
4. Trigger qcom_slim_ngd_ssr_pdr_notify or related callbacks before NGD work structures are valid.
5. Cause a kernel warning, failed driver initialization, boot failure, or device/service denial of service.

How to detect it

Look for prior exploitation or triggering by reviewing kernel logs, system journals, crash dumps, pstore/ramoops records, console logs, device telemetry, and boot failure reports for warning traces or crashes in the Qualcomm SLIMbus NGD controller path. Relevant artifacts include kernel workqueue warnings during boot or remote processor startup, call traces referencing qcom_slim_ngd_ssr_pdr_notify or qcom_slim_ngd_ssr_notify, failures around rproc_start or rproc_boot, and module references to slim_qcom_ngd_ctrl. Because this issue is primarily a race/reliability flaw and no public exploitation is reported, detections should focus on evidence that the vulnerable code path was triggered, then correlate with local admin activity, driver reloads, reboot loops, subsystem restart events, firmware updates, suspend/resume cycles, or physical/device-management actions. Preserve crash dumps and early boot logs where possible, as the most useful evidence may be lost after reboot.

• WARNING: kernel/workqueue.c:2338
• __queue_work+0x5e0/0x790
• queue_work_on+0x6c/0xf0
• qcom_slim_ngd_ssr_pdr_notify
• qcom_slim_ngd_ssr_notify
• slim_qcom_ngd_ctrl
• ssr_notify_start
• rproc_start
• rproc_boot
• notifier_call_chain
• srcu_notifier_call_chain
• schedules work on the NULL ngd_up_work
• NULL ngd_up_work
• slimbus: qcom-ngd-ctrl

What your security team should do

• Inventory Linux devices and products using Qualcomm SoCs and kernels that include the slim_qcom_ngd_ctrl or qcom-ngd-ctrl SLIMbus driver.
• Prioritize remediation for production embedded, mobile, IoT, automotive, appliance, or edge devices where boot reliability and physical availability are business-critical.
• Apply the kernel, BSP, firmware, or OS vendor update that includes the corrected NGD initialization and callback registration ordering.
• If updates cannot be applied immediately, restrict local administrative access and operational workflows that reload drivers, restart remote processors, or repeatedly reboot exposed devices.
• Add monitoring for kernel warnings and stack traces involving qcom_slim_ngd_ssr_pdr_notify, qcom_slim_ngd_ssr_notify, slim_qcom_ngd_ctrl, __queue_work, rproc_start, and rproc_boot.
• Run regression testing focused on boot, reboot, suspend/resume, and subsystem restart reliability after patching.
• Treat alerts as reliability or denial-of-service signals unless additional evidence indicates malicious local triggering, because no active exploitation or ransomware use is reported in the provided data.