Arend van Spriel <arend.vanspriel@xxxxxxxxxxxx> 于2023年11月13日周一 17:18写道： > > On November 8, 2023 4:03:26 AM Zheng Hacker <hackerzheng666@xxxxxxxxx> > wrote: > > > Arend Van Spriel <arend.vanspriel@xxxxxxxxxxxx> 于2023年11月6日周一 23:48写道： > >> > >> On November 6, 2023 3:44:53 PM Zheng Hacker <hackerzheng666@xxxxxxxxx> wrote: > >> > >>> Thanks! I didn't test it for I don't have a device. Very appreciated > >>> if anyone could help with that. > >> > >> I would volunteer, but it made me dig deep and not sure if there is a > >> problem to solve here. > >> > >> brcmf_cfg80211_detach() calls wl_deinit_priv() -> brcmf_abort_scanning() -> > >> brcmf_notify_escan_complete() which does delete the timer. > >> > >> What am I missing here? > > > > Thanks four your detailed review. I did see the code and not sure if > > brcmf_notify_escan_complete > > would be triggered for sure. So in the first version I want to delete > > the pending timer ahead of time. > > Why requesting a CVE when you are not sure? Seems a bit hasty to put it > mildly. I'm sure the issue exists because there's only cancler of timer but not woker. As there's similar CVEs before like : https://github.com/V4bel/CVE-2022-41218, I submit it as soon as I found it. > > > As I'm not very familiar with the logic here. I'm still not sure if we > > should delete the timer_shutdown_sync. > > Looking forward to your reply :) > > Reading the kerneldoc of timer_shutdown_sync() has the advantage that > the timer can not be rearmed by another thread. However, that will only > happen when a new scan is initiated in firmware, but the bus is already > down so that can not happen. The only improvement (no bug fix!) I see > here is to replace timer handling code in brcmf_notify_escan_complete(): > > - if (timer_pending(&cfg->escan_timeout)) > - del_timer_sync(&cfg->escan_timeout); > + timer_delete_sync(&cfg->escan_timeout); > Very thanks for your reviews and suggestions! I thinks it's a good idea. I'll make another patch sooner or later. Best regards, Zheng > Regards, > Arend
