Messages in this thread | | | Date | Sat, 9 Apr 2022 17:10:05 +0200 | Subject | Re: [PATCH] drivers: nfc: nfcmrvl: fix UAF bug in nfcmrvl_nci_unregister_dev() | From | Krzysztof Kozlowski <> |
| |
On 09/04/2022 15:58, Duoming Zhou 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?
> 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); > }
Best regards, Krzysztof
| |