CVE-2026-53158: Linux Kernel Use-After-Free Vulnerability

CVE-2026-53158 Overview

CVE-2026-53158 is a NULL pointer dereference vulnerability in the Linux kernel's fastrpc misc driver. The flaw resides in the fastrpc_rpmsg_callback() function, which handles glink messages from a Digital Signal Processor (DSP). The kernel observed the dereference on Hawi at boot when the DSP sent a glink message before fastrpc_rpmsg_probe() finished initialization. The faulting address 0x178 corresponds to the lock variable inside struct fastrpc_channel_ctx, confirming that cctx was NULL when the callback attempted to acquire the spinlock. The condition produces a kernel oops and a denial-of-service condition on affected systems.

Critical Impact
A race during driver probe lets an early DSP glink message trigger a NULL pointer dereference in kernel context, crashing the system at boot.

Affected Products

Linux kernel fastrpc misc driver (Qualcomm FastRPC over glink/rpmsg)
Platforms using Qualcomm DSP subsystems that interact with fastrpc_rpmsg_callback() (observed on Hawi)
Kernel versions prior to the fixes referenced in the upstream stable commits

Discovery Timeline

2026-06-25 - CVE-2026-53158 published to the National Vulnerability Database (NVD)
2026-06-25 - Last updated in NVD database

Technical Details for CVE-2026-53158

Vulnerability Analysis

The fastrpc driver registers an rpmsg channel that becomes live as soon as the driver is bound. The kernel call trace shows the crash path: _raw_spin_lock_irqsave invoked from fastrpc_rpmsg_callback+0x3c/0xcc, reached via qcom_glink_native_rx and qcom_glink_smem_intr. The callback retrieves the channel context through dev_get_drvdata() and then takes a spinlock inside struct fastrpc_channel_ctx. When the DSP sends a glink message before probe initialization completes, the callback operates on a structure that is either NULL or only partially initialized. The resulting dereference of virtual address 0x178 terminates the kernel thread and renders the system unusable until reboot or recovery.

Root Cause

The defect has two distinct windows. First, dev_set_drvdata() is called before spin_lock_init() and idr_init(), so the callback can retrieve a valid cctx pointer while the embedded spinlock is still uninitialized. Second, the rpmsg channel becomes live the moment the driver is bound, so fastrpc_rpmsg_callback() can fire before dev_set_drvdata() is ever reached, causing dev_get_drvdata() to return NULL. Both paths converge on an unsafe spinlock acquisition. The class of defect maps to a NULL pointer dereference combined with a probe-time race condition.

Attack Vector

The trigger requires a glink message from the DSP arriving during the narrow probe window. The vector is local to the device firmware and kernel subsystem boundary, not network-exposed. A compromised or misbehaving DSP image, abnormal boot timing, or deliberate manipulation of remoteproc start ordering can reproduce the condition. The practical outcome is a kernel crash and denial of service rather than code execution. No verified public exploit is referenced in the advisory data.

No verified proof-of-concept code is available. See the upstream commits for the precise source-level fix: Kernel commit 4bfdf0a9855d, Kernel commit 5401fb4fe10f, Kernel commit 8fb4a23df5b7, Kernel commit d5de9cb5355d, and Kernel commit d77583ca3329.

Detection Methods for CVE-2026-53158

Indicators of Compromise

Kernel oops messages containing Unable to handle kernel NULL pointer dereference at virtual address 0000000000000178 during early boot.
Backtraces that include fastrpc_rpmsg_callback, qcom_glink_native_rx, and qcom_glink_smem_intr.
Repeated boot loops or unexpected resets on Qualcomm DSP-equipped platforms shortly after fastrpc module load.

Detection Strategies

Parse dmesg and persistent kernel logs (/var/log/kern.log, pstore, ramoops) for the signature spinlock fault chain referenced above.
Correlate crash timestamps with fastrpc and qcom_glink_smem module load events to confirm the probe race window.
Inventory deployed kernel versions and flag any host running a fastrpc build that predates the upstream fixes.

Monitoring Recommendations

Forward kernel panic and oops events to a centralized log pipeline for fleet-wide visibility.
Track boot success rates on Qualcomm-based devices and alert on a sudden rise in early-boot failures.
Monitor remoteproc and rpmsg subsystem messages for unusual ordering between DSP bring-up and fastrpc probe completion.

How to Mitigate CVE-2026-53158

Immediate Actions Required

Apply the upstream Linux kernel patches that reorder cctx initialization before dev_set_drvdata() and add a NULL guard in fastrpc_rpmsg_callback().
Rebuild and deploy vendor kernels for Qualcomm DSP platforms that integrate the fastrpc driver.
Verify that recovery mechanisms such as watchdog reset and A/B boot slots are enabled to limit impact during rollout.

Patch Information

The fix moves all cctx initialization, including spin_lock_init() and idr_init(), ahead of dev_set_drvdata() so the structure is fully initialized before it becomes visible to the callback. A NULL check is added in fastrpc_rpmsg_callback() as a guard against any remaining window. Stable backports are tracked under Kernel commit 4bfdf0a9855d, Kernel commit 5401fb4fe10f, Kernel commit 8fb4a23df5b7, Kernel commit d5de9cb5355d, and Kernel commit d77583ca3329.

Workarounds

Blacklist the fastrpc module on systems that do not require DSP offload until the patched kernel is deployed.
Delay or gate DSP firmware loading via remoteproc so glink traffic cannot begin before the fastrpc driver finishes probing.
Constrain physical and administrative access to devices that load untrusted DSP firmware images to reduce the chance of triggering the race.

bash

# Temporarily prevent the vulnerable driver from loading until patched kernel is in place
echo "blacklist fastrpc" | sudo tee /etc/modprobe.d/blacklist-fastrpc.conf
sudo update-initramfs -u

# Verify running kernel version after patch deployment
uname -r
modinfo fastrpc | grep -E '^(version|srcversion|filename):'