CVE-2026-53158

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 fastrpcrpmsgprobe() has completed initialization:

Unable to handle kernel NULL pointer dereference at virtual address 0000000000000178 pc : rawspinlockirqsave+0x34/0x8c lr : fastrpcrpmsgcallback+0x3c/0xcc [fastrpc] ... Call trace: rawspinlockirqsave+0x34/0x8c (P) fastrpcrpmsgcallback+0x3c/0xcc [fastrpc] qcomglinknativerx+0x538/0x6a4 qcomglinksmemintr+0x14/0x24 [qcomglinksmem]

The faulting address 0x178 corresponds to the lock variable inside struct fastrpcchannelctx, confirming that cctx is NULL when fastrpcrpmsgcallback() attempts to take the spinlock.

There are two issues here. First, devsetdrvdata() is called before spinlockinit() and idrinit(), 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 fastrpcrpmsgcallback() can fire before devsetdrvdata() is called at all, resulting in devget_drvdata() returning NULL.

Fix both issues by moving all cctx initialization ahead of devsetdrvdata() so the structure is fully initialized before it becomes visible to the callback, and add a NULL check in fastrpcrpmsgcallback() as a guard against any remaining window.