On November 16, 2023 7:25:16 PM Takashi Iwai <tiwai@xxxxxxx> wrote:
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).
Hi Takashi, You are obviously right. Let's wait and see what v6 will look like ;-) Regards, Arend
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
