CVE-2026-53158

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> misc: fastrpc: Fix NULL pointer dereference in rpmsg callback<br /> <br /> A NULL pointer dereference was observed on Hawi at boot when the DSP<br /> sends a glink message before fastrpc_rpmsg_probe() has completed<br /> initialization:<br /> <br /> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000178<br /> pc : _raw_spin_lock_irqsave+0x34/0x8c<br /> lr : fastrpc_rpmsg_callback+0x3c/0xcc [fastrpc]<br /> ...<br /> Call trace:<br /> _raw_spin_lock_irqsave+0x34/0x8c (P)<br /> fastrpc_rpmsg_callback+0x3c/0xcc [fastrpc]<br /> qcom_glink_native_rx+0x538/0x6a4<br /> qcom_glink_smem_intr+0x14/0x24 [qcom_glink_smem]<br /> <br /> The faulting address 0x178 corresponds to the lock variable inside<br /> struct fastrpc_channel_ctx, confirming that cctx is NULL when<br /> fastrpc_rpmsg_callback() attempts to take the spinlock.<br /> <br /> There are two issues here. First, dev_set_drvdata() is called before<br /> spin_lock_init() and idr_init(), leaving a window where the callback<br /> can retrieve a valid cctx pointer but operate on an uninitialized<br /> spinlock. Second, the rpmsg channel becomes live as soon as the driver<br /> is bound, so fastrpc_rpmsg_callback() can fire before dev_set_drvdata()<br /> is called at all, resulting in dev_get_drvdata() returning NULL.<br /> <br /> Fix both issues by moving all cctx initialization ahead of<br /> dev_set_drvdata() so the structure is fully initialized before it<br /> becomes visible to the callback, and add a NULL check in<br /> fastrpc_rpmsg_callback() as a guard against any remaining window.