Re: [PATCH 5.15.y] wifi: brcmfmac: fix use-after-free when rescheduling brcmf_btcoex_info work

[Sasha Levin <sashal@kernel.org>]

> The upstream fix uses timer_shutdown_sync() which prevents the timer from
> being re-armed after it returns. del_timer_sync() does not have this
> guarantee.
>
> brcmf_btcoex_handler() has three mod_timer() calls - two in
> BRCMF_BT_DHCP_START and one in BRCMF_BT_DHCP_OPPR_WIN - none of which are
> guarded by timer_on. A work item running between del_timer_sync() and
> cancel_work_sync() can re-arm the timer, leaving it pending when kfree() is
> called.

Agreed on the analysis. One thing to note: this backport already
shipped in v5.15.210, and 6.1.y shipped the same weakened
del_timer_sync() variant in v6.1.167, so this needs follow-up patches
rather than a v2 of the original.

> If the mod_timer() calls were made conditional on timer_on, setting
> timer_on = false before del_timer_sync() would be sufficient. That would be
> my preferred fix. Alternatively a second del_timer_sync() after
> cancel_work_sync() would also work.
>
> Also the commit message still mentions timer_shutdown_sync() rather than
> del_timer_sync().

There's a simpler option: timer_shutdown_sync() is actually available
in both 5.15.y and 6.1.y, so the del_timer_sync() substitution was
never necessary in the first place. A one-line follow-up converting
del_timer_sync() to timer_shutdown_sync() makes brcmf_btcoex_detach()
match the upstream post-image exactly, closes the re-arm window you
describe, and avoids a stable-only divergence guarding the mod_timer()
calls.

Robert, could you send follow-up patches for 5.15.y and 6.1.y doing
that conversion?

-- 
Thanks,
Sasha