CVE-2026-53158

What it actually does

This is a race-condition flaw in the Linux kernel Qualcomm FastRPC driver. During rpmsg/glink channel initialization, the DSP can deliver a message before the FastRPC channel context is fully initialized or before driver data has been attached. The callback can then dereference a NULL or partially initialized channel context and attempt to take an uninitialized spinlock, causing a kernel NULL pointer dereference and likely kernel panic or boot-time crash. The primary technical impact is denial of service on systems using the affected Qualcomm FastRPC/rpmsg/glink path; there is no public evidence of code execution or privilege escalation.

Why it matters to the business

Affected Linux systems, especially Qualcomm-based embedded, mobile, edge, or appliance platforms using FastRPC with DSP communication, may crash or fail during boot if the race is triggered. This can cause device unavailability, service interruption, failed updates, increased support costs, or fleet instability. The risk is currently lower than actively exploited vulnerabilities because it is not in CISA KEV, has very low EPSS, and has no known public exploit maturity, but it should still be addressed in kernel maintenance cycles for reliability and availability.

How an attack unfolds

An attacker would need a way to influence or cause early DSP-to-application-processor rpmsg/glink traffic while the FastRPC driver is binding and initializing. If a message arrives before the driver has completed initialization, the FastRPC callback may retrieve no channel context or a partially initialized one. The callback then attempts to use fields such as the channel lock, triggering a NULL pointer dereference in kernel context. In practical terms, exploitation is most plausible through a malicious, compromised, or malfunctioning DSP/firmware component, a device-specific boot sequence that races driver initialization, or local access to interfaces that can influence DSP messaging. Successful exploitation would normally crash the kernel or prevent clean boot rather than provide direct attacker control.

How to fix it

Apply a Linux kernel update that includes the FastRPC fix moving channel context initialization before dev_set_drvdata() and adding a NULL guard in fastrpc_rpmsg_callback(). Because no product-specific fixed versions were provided, use the fixed kernel release or vendor advisory applicable to the device, distribution, BSP, Android kernel branch, or embedded platform. For systems that cannot be immediately updated, reduce exposure by limiting untrusted firmware, disabling unused DSP/FastRPC functionality where operationally feasible, validating DSP firmware provenance, and testing boot stability after firmware or kernel changes. Kernel module blacklisting may mitigate exposure only if FastRPC is not required by the platform workload.

How to confirm the fix worked

Confirm that the running kernel contains the FastRPC rpmsg callback fix from the applicable upstream, distribution, or vendor kernel source. Validate by checking the deployed kernel package/build against the vendor fixed version or by reviewing the fastrpc driver source for initialization before dev_set_drvdata() and a NULL check in fastrpc_rpmsg_callback(). Reboot affected hardware and monitor kernel logs for absence of FastRPC-related NULL pointer dereferences, qcom_glink receive-path crashes, or boot-time kernel panics. On managed fleets, inventory systems with Qualcomm FastRPC/rpmsg/glink support and verify that all have moved to a patched kernel or approved vendor firmware/kernel bundle.

Typical attack path

1. Identify a Linux device using the Qualcomm FastRPC driver and rpmsg/glink communication with a DSP.
2. Gain the ability to influence DSP firmware behavior, DSP-originated messages, or timing of rpmsg/glink traffic during driver initialization.
3. Trigger an rpmsg/glink message before fastrpc_rpmsg_probe() has completed channel context initialization and driver data registration.
4. Cause fastrpc_rpmsg_callback() to run with a NULL or partially initialized channel context.
5. Trigger a kernel NULL pointer dereference, resulting in kernel oops, panic, reboot, or boot failure.

How to detect it

Review kernel logs, serial console output, pstore/ramoops records, crash dumps, and device management telemetry for boot-time kernel oops or panic events involving fastrpc_rpmsg_callback, fastrpc, qcom_glink_native_rx, or qcom_glink_smem_intr. Focus on crashes shortly after boot, driver binding, firmware loading, or DSP initialization. Useful artifacts include NULL pointer dereference messages, call traces showing the FastRPC rpmsg callback, faulting addresses near 0x178, and repeated reboot loops on Qualcomm platforms. Because exploitation requires device-specific timing or DSP message influence and no public exploit is known, detections should be triaged alongside firmware changes, kernel updates, hardware faults, and boot-sequence regressions.

• Unable to handle kernel NULL pointer dereference at virtual address 0000000000000178
• fastrpc_rpmsg_callback
• Call trace:
• _raw_spin_lock_irqsave
• qcom_glink_native_rx
• qcom_glink_smem_intr
• [fastrpc]
• [qcom_glink_smem]
• kernel NULL pointer dereference
• pc : _raw_spin_lock_irqsave
• lr : fastrpc_rpmsg_callback

What your security team should do

• Prioritize patching Qualcomm-based Linux, Android, embedded, edge, and appliance platforms that load the fastrpc driver or rely on DSP FastRPC services.
• Ask vendors or BSP maintainers for the kernel build that contains the FastRPC rpmsg callback NULL-dereference fix if no fixed package version is listed in standard advisories.
• Search historical kernel logs, crash dumps, pstore/ramoops, and device telemetry for FastRPC, qcom_glink, or NULL pointer dereference crashes during boot.
• Treat repeated boot-time crashes in the FastRPC/glink path as potential exploitation, firmware malfunction, or regression until root cause is confirmed.
• Restrict deployment of unsigned, untrusted, or non-vendor DSP firmware and include DSP firmware changes in security review and release testing.
• For devices where FastRPC is unnecessary, evaluate disabling or not loading the fastrpc module as a compensating control.
• Track this vulnerability at normal kernel-maintenance priority unless threat intelligence changes, because it is not currently KEV-listed, has no known ransomware association, and has very low EPSS.