misc: fastrpc: Fix NULL pointer dereference in rpmsg callback

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.