On 2019-09-04 10:14 AM, Anson Huang wrote: > The SCU firmware API for getting UID should have response, > otherwise, the message stored in function stack could be > released and then the response data received from SCU will be > stored into that released stack and cause kernel NULL pointer > dump.
This fix looks good, but looking at imx-scu code it seems that passing the incorrect "have_resp" argument to imx_scu_call_rpc or just receiving an unexpected message from SCFW will always result in kernel stack corruption! This is worth handling inside imx-scu itself: unless a response was explicitly requested it should ignore and print a warning on rx, for example by setting imx_sc_ipc to NULL when not waiting for a response. Holding on to arbitrary stack pointers is bad. -- Regards, Leonard > diff --git a/drivers/soc/imx/soc-imx-scu.c b/drivers/soc/imx/soc-imx-scu.c > index 50831eb..c68882e 100644 > --- a/drivers/soc/imx/soc-imx-scu.c > +++ b/drivers/soc/imx/soc-imx-scu.c > @@ -46,7 +46,7 @@ static ssize_t soc_uid_show(struct device *dev, > hdr->func = IMX_SC_MISC_FUNC_UNIQUE_ID; > hdr->size = 1; > > - ret = imx_scu_call_rpc(soc_ipc_handle, &msg, false); > + ret = imx_scu_call_rpc(soc_ipc_handle, &msg, true); > if (ret) { > pr_err("%s: get soc uid failed, ret %d\n", __func__, ret); > return ret;