PT-2026-52254 · Linux · Linux

Publicado

2026-06-25

·

Atualizado

2026-06-25

·

CVE-2026-53158

Nenhuma

Não há classificações de severidade ou métricas disponíveis. Quando houver, atualizaremos as informações correspondentes na página.
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.
Encontrou algum problema na descrição? Tem algo a acrescentar? Fique à vontade para nos escrever 👾
dbugs@ptsecurity.com

Identificadores relacionados

CVE-2026-53158

Produtos afetados

Linux