PT-2026-52254 · Linux · Linux
Published
2026-06-25
·
Updated
2026-06-25
·
CVE-2026-53158
None
No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
In the Linux kernel, the following vulnerability has been resolved:
misc: fastrpc: Fix NULL pointer dereference in rpmsg callback
A NULL pointer dereference was observed on Hawi at boot when the DSP
sends a glink message before fastrpc rpmsg probe() has completed
initialization:
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000178
pc : raw spin lock irqsave+0x34/0x8c
lr : fastrpc rpmsg callback+0x3c/0xcc [fastrpc]
...
Call trace:
raw spin lock irqsave+0x34/0x8c (P)
fastrpc rpmsg callback+0x3c/0xcc [fastrpc]
qcom glink native rx+0x538/0x6a4
qcom glink smem intr+0x14/0x24 [qcom glink smem]
The faulting address 0x178 corresponds to the lock variable inside
struct fastrpc channel ctx, confirming that cctx is NULL when
fastrpc rpmsg callback() attempts to take the spinlock.
There are two issues here. First, dev set drvdata() is called before
spin lock init() and idr init(), leaving a window where the callback
can retrieve a valid cctx pointer but operate on an uninitialized
spinlock. Second, the rpmsg channel becomes live as soon as the driver
is bound, so fastrpc rpmsg callback() can fire before dev set drvdata()
is called at all, resulting in dev get drvdata() returning NULL.
Fix both issues by moving all cctx initialization ahead of
dev set drvdata() so the structure is fully initialized before it
becomes visible to the callback, and add a NULL check in
fastrpc rpmsg callback() as a guard against any remaining window.
Found an issue in the description? Have something to add? Feel free to write us 👾
Related Identifiers
Affected Products
Linux