Yes, that makes this issue hard to fix. I was wondering why it binds the worker with the timer rather than using just one of them. Takashi Iwai <tiwai@xxxxxxx> 于2023年11月17日周五 02:25写道： > > On Thu, 16 Nov 2023 19:20:06 +0100, > Arend Van Spriel wrote: > > > > On November 15, 2023 4:00:46 PM Zheng Hacker <hackerzheng666@xxxxxxxxx> wrote: > > > > > 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. > > > > Ah, yes. The cancel_work_sync() can also be done in > > brcmf_notify_escan_complete(). > > AFAIUC, brcmf_notify_scan_complete() is called from the work itself, > too, hence you can't issue cancel_work_sync() there (unless you make > it conditional). > > > Takashi
