Messages in this thread Patch in this message |  | | Date | Sun, 10 Apr 2022 16:30:55 +0800 (GMT+08:00) | From | duoming@zju ... | 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@zju.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
|  |