RE: [PATCH v36 3/7] firmware: imx: add driver for NXP EdgeLock Enclave

> > > +void se_if_rx_callback(struct mbox_client *mbox_cl, void *msg) {
> > [ ... ]
> > > + } else if (header->tag == priv->if_defs->rsp_tag) {
> > [ ... ]
> > > +         se_clbk_hdl->rx_msg_sz = min(rx_msg_sz, exp_rx_msg_sz);
> > > +         memcpy(se_clbk_hdl->rx_msg, msg, se_clbk_hdl->rx_msg_sz);
> >
> > [Severity: High]
> > If the mailbox controller driver passes a pointer to a small local
> > buffer on the IRQ stack for msg, but the untrusted firmware-provided
> > header->size specifies a large size, does this memcpy() read
> > out-of-bounds past the msg pointer capacity?
>
> Please check this also
>
> Frank
>

Not an issue.
rx_msg_sz is derived from the firmware-provided header->size field.
It is safe to use as the source length for the memcpy() calls below
because the MU mailbox driver (imx-mailbox.c) already validates that
header->size does not exceed the capacity of its own fixed-size
priv->msg buffer (sizeof(imx_sc_rpc_msg_max) = 124 bytes for
i.MX8/i.MX93, sizeof(imx_s4_rpc_msg_max) = 1020 bytes for S4
variants).  If firmware reports an oversized length the mailbox driver
returns -EINVAL and never invokes this callback, so rx_msg_sz here is
always <= the capacity of the msg pointer.  The min() / min_t() calls
below additionally clamp the copy to the destination buffer size.

>
> > --
> > Sashiko AI review *
> > https://sashiko.dev/#/patchset/20260817-imx-se-if-v36-0-
> 45c42847bfd8@o
> > ss.nxp.com?part=3

NXP Confidential