[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <37334368.2629.1801298f436.Coremail.duoming@zju.edu.cn>
Date: Sun, 10 Apr 2022 16:30:55 +0800 (GMT+08:00)
From: duoming@....edu.cn
To: "Krzysztof Kozlowski" <krzysztof.kozlowski@...aro.org>
Cc: linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
alexander.deucher@....com, gregkh@...uxfoundation.org,
davem@...emloft.net
Subject: Re: Re: [PATCH] drivers: nfc: nfcmrvl: fix UAF bug in
nfcmrvl_nci_unregister_dev()
Hello,
I am sorry for the delay.
On Sat, 9 Apr 2022 17:10:05 +0200 Krzysztof Kozlowski wrote:
> > There is a potential UAF bug in nfcmrvl usb driver between
> > unregister and resume operation.
> >
> > The race that cause that UAF can be shown as below:
> >
> > (FREE) | (USE)
> > | nfcmrvl_resume
> > | nfcmrvl_submit_bulk_urb
> > | nfcmrvl_bulk_complete
> > | nfcmrvl_nci_recv_frame
> > | nfcmrvl_fw_dnld_recv_frame
> > | skb_queue_tail
> > nfcmrvl_disconnect |
> > nfcmrvl_nci_unregister_dev |
> > nfcmrvl_fw_dnld_deinit | ...
> > destroy_workqueue //(1) |
> > ... | queue_work //(2)
> >
> > When nfcmrvl usb driver is resuming, we detach the device.
> > The workqueue is destroyed in position (1), but it will be
> > latter used in position (2), which leads to data race.
>
> I miss here something. How can you queue work on a destroyed workqueue?
> When workqueue is destroyed, no more work should be executed. Unless you
> mean the case that draining the work (during destroying, not after)
> causes the (2) to happen?
Sorry, I make a mistake in my patch. The destroy_workqueue() will not
return until all work is finished. So the UAF bug is not exist.
Actually, there is a double free bug in nfcmrvl_nci_unregister_dev(). The root
cause is shown below:
(FREE) | (USE)
| nfcmrvl_resume
| nfcmrvl_submit_bulk_urb
| nfcmrvl_bulk_complete
| nfcmrvl_nci_recv_frame
| nfcmrvl_fw_dnld_recv_frame
| queue_work
| fw_dnld_rx_work
| fw_dnld_over
| release_firmware
| kfree(fw); //(1)
nfcmrvl_disconnect |
nfcmrvl_nci_unregister_dev |
nfcmrvl_fw_dnld_abort |
fw_dnld_over | ...
if (priv->fw_dnld.fw) |
release_firmware |
kfree(fw); //(2) |
... | fw = NULL;
When nfcmrvl usb driver is resuming, we detach the device.
The release_firmware() will deallocate firmware in position (1),
but firmware will be deallocate again in position (2), which
leads to double free.
> > This patch reorders the nfcmrvl_fw_dnld_deinit after
> > nci_unregister_device in order to prevent UAF. Because
> > nci_unregister_device will not return until finish all
> > operations from upper layer.
> >
> > Signed-off-by: Duoming Zhou <duoming@....edu.cn>
> > ---
> > drivers/nfc/nfcmrvl/main.c | 3 +--
> > 1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/drivers/nfc/nfcmrvl/main.c b/drivers/nfc/nfcmrvl/main.c
> > index 2fcf545012b..5ed17b23ee8 100644
> > --- a/drivers/nfc/nfcmrvl/main.c
> > +++ b/drivers/nfc/nfcmrvl/main.c
> > @@ -186,12 +186,11 @@ void nfcmrvl_nci_unregister_dev(struct nfcmrvl_private *priv)
> > if (priv->ndev->nfc_dev->fw_download_in_progress)
> > nfcmrvl_fw_dnld_abort(priv);
> >
> > - nfcmrvl_fw_dnld_deinit(priv);
> > -
> > if (gpio_is_valid(priv->config.reset_n_io))
> > gpio_free(priv->config.reset_n_io);
> >
> > nci_unregister_device(ndev);
> > + nfcmrvl_fw_dnld_deinit(priv);
>
> The new order matches reverse-probe, so actually makes sense.
>
> > nci_free_device(ndev);
> > kfree(priv);
> > }
I will send "[PATCH] drivers: nfc: nfcmrvl: fix double free bug in
nfcmrvl_nci_unregister_dev()" as soon as possible.
Best regards,
Duoming Zhou
Powered by blists - more mailing lists