Re: [PATCH v1] firmware: arm_scmi: Fix NULL pointer dereference in mailbox_clear_channel

[Qiujun Huang]

On Thu, Aug 31, 2023 at 8:34 PM Sudeep Holla <sudeep.holla@xxxxxxx> wrote:
>
> On Wed, Aug 30, 2023 at 09:23:58PM +0800, Qiujun Huang wrote:
> >
> >
> > > 2023年8月30日 下午5:39，Sudeep Holla <sudeep.holla@xxxxxxx> 写道：
> > >
> > > On Wed, Aug 30, 2023 at 01:07:47AM +0800, Qiujun Huang wrote:
> > >> There is a race between the failure of probe and rx_callback (due to a
> > >> delayed response).
> > >>
> > >> scmi_probe
> > >> scmi_acquire_protocal
> > >> do_xfer
> > >> timeout
> > >> mailbox_chan_free
> > >>                                                    <--- delay response
> > >>                                                           rx_callback
> > >> mbox_free_channel
> > >> cinfo->transport_info = NULL
> > >>                                                          mailbox_clear_channel
> > >>                                                         dereference cinfo->transport_info
> > >
> > > It is always good to provide the kernel stacktrace which you get when a
> > > NULL pointer is dereference. It helps for review and also to document it.
> > >
> > > --
> > > Regards,
> > > Sudeep
> >
> > Get it. Here is the splat.
> >
> > [    1.942240][    C0] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000048
> > [    1.942241][    C0] Mem abort info:
> > [    1.942243][    C0]   ESR = 0x96000005
> > [    1.944888][    T9] spmi spmi-1: PMIC arbiter version v7 (0x70000000)
> > [    1.950652][    C0]   EC = 0x25: DABT (current EL), IL = 32 bits
> > [    1.950653][    C0]   SET = 0, FnV = 0
> > [    1.950654][    C0]   EA = 0, S1PTW = 0
> > [    1.950656][    C0] Data abort info:
> > [    1.950657][    C0]   ISV = 0, ISS = 0x00000005
> > [    1.950658][    C0]   CM = 0, WnR = 0
> > [    1.950660][    C0] [0000000000000048] user address but active_mm is swapper
> > [    1.950663][    C0] Internal error: Oops: 96000005 [#1] PREEMPT SMP
> > [    2.338929][    C0] pc : mailbox_clear_channel+0x18/0x64
> > [    2.344384][    C0] lr : scmi_handle_response+0x17c/0x4f4
> > [    2.349923][    C0] sp : ffffffc010003db0
> > [    2.354045][    C0] x29: ffffffc010003dc0 x28: ffffffd85263f000
> > [    2.360216][    C0] x27: ffffffd851621068 x26: ffffffd84ec815c8
> > [    2.366386][    C0] x25: ffffffd85263bf80 x24: ffffffd85263d230
> > [    2.372556][    C0] x23: ffffff803cd70cc0 x22: 0000000000000008
> > [    2.378726][    C0] x21: ffffff8036cf0df8 x20: ffffffd85161bac8
> > [    2.384896][    C0] x19: ffffff8043ffa580 x18: ffffffc010005050
> > [    2.391065][    C0] x17: 0000000000000000 x16: 00000000000000d8
> > [    2.397234][    C0] x15: ffffffd8507965e8 x14: ffffffd84eaebdf0
> > [    2.403404][    C0] x13: 00000000000001ea x12: 0000000000007ffb
> > [    2.409574][    C0] x11: 000000000000ffff x10: ffffffd852c5a000
> > [    2.415744][    C0] x9 : d7be1a9b75f29500 x8 : 0000000000000000
> > [    2.421914][    C0] x7 : 382e31202020205b x6 : ffffffd852c57e7c
> > [    2.428084][    C0] x5 : ffffffffffffffff x4 : 0000000000000000
> > [    2.434254][    C0] x3 : ffffffd84eae6668 x2 : 0000000000000001
> > [    2.440424][    C0] x1 : 0000000000000000 x0 : ffffff8043ffa580
> > [    2.446594][    C0] Call trace:
> > [    2.449819][    C0]  mailbox_clear_channel+0x18/0x64
>
> Is this with latest kernel ? IIUC the mailbox_clear_channel should get called
no, it's on 5.10-stable kernel
> only for delayed response and notification in this path(scmi_handle_response).
> You are saying it happens as part of probe and again IIUC probe doesn't have
> any delayed response command. What am I missing ?
>
> Any additional changes in the tree ? My build has much smaller
> mailbox_clear_channel.
>
> > [    2.454916][    C0]  scmi_handle_response+0x17c/0x4f4
> > [    2.460100][    C0]  rx_callback+0x60/0xec
> > [    2.464311][    C0]  mbox_chan_received_data+0x44/0x94
> > [    2.469584][    C0]  qcom_rimps_rx_interrupt+0xc0/0x144 [qcom_rimps]
>
> This suggests out of tree driver, any pointers ?
>
> Also I vaguely remember discussing this in the past. Perhaps at [1] or
> somewhere else.
Get that. It looks painful
>
> --
> Regards,
> Sudeep
>
> [1] https://lore.kernel.org/linux-arm-kernel/cfa26ff3-c95a-1986-58fc-b49fc9be49d5@xxxxxxxxxxx/