linux-kernel - Re: [PATCH] brcmfmac: btcoex: Fix use-after-free when rescheduling brcmf_btcoex

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <5c6b3d94.1a56d.198cffcee28.Coremail.duoming@zju.edu.cn>
Date: Fri, 22 Aug 2025 12:15:16 +0800 (GMT+08:00)
From: duoming@....edu.cn
To: "Arend van Spriel" <arend.vanspriel@...adcom.com>
Cc: brcm80211@...ts.linux.dev, brcm80211-dev-list.pdl@...adcom.com,
	linux-kernel@...r.kernel.org, linux-wireless@...r.kernel.org,
	mingo@...nel.org, tglx@...utronix.de
Subject: Re: [PATCH] brcmfmac: btcoex: Fix use-after-free when rescheduling
 brcmf_btcoex_info work

On Thu, 21 Aug 2025 20:44:21 +0200 Arend van Spriel wrote:
> > The brcmf_btcoex_detach() only shuts down the btcoex timer, if the
> > flag timer_on is false. However, the brcmf_btcoex_timerfunc(), which
> > runs as timer handler, sets timer_on to false. This creates a critical
> > race condition:
> > 
> > 1.If brcmf_btcoex_detach() is called while brcmf_btcoex_timerfunc()
> > is executing, it may observe timer_on as false and skip the call to
> > timer_shutdown_sync().
> > 
> > 2.The brcmf_btcoex_timerfunc() may then reschedule the brcmf_btcoex_info
> > worker after the cancel_work_sync() has been executed.
> > 
> > 3.Subsequently, the brcmf_btcoex_info structure is freed.
> > 
> > 4.Finally, the rescheduled worker attempts to execute, leading to
> > use-after-free bugs by accessing the freed brcmf_btcoex_info object.
> 
> Thanks for the patch. Being a nit picker just wanted to day that the 
> use-after-free happens a bit earlier as the worker itself is contained 
> in struct brcmf_btcoex_info. Also the diagram below does not add much 
> more than the textual description above.

Thank you very much for your guidance.

The use-after-free bugs occur in two distinct scenarios, depending on 
the timing of when the brcmf_btcoex_info struct is freed relative to 
the execution of its worker thread.

Scenario 1: Freed before the worker is scheduled

The brcmf_btcoex_info is deallocated before the worker is scheduled. 
A race condition can occur when schedule_work(&bt_local->work) is 
called after the target memory has been freed. The sequence of events 
is detailed below:

CPU0                           | CPU1
brcmf_btcoex_detach            | brcmf_btcoex_timerfunc
                               |   bt_local->timer_on = false;
  if (cfg->btcoex->timer_on)   |
    ...                        |
  cancel_work_sync();          |
  ...                          |
  kfree(cfg->btcoex); // FREE  |
                               |   schedule_work(&bt_local->work); // USE

Scenario 2: Freed after the worker is scheduled

The brcmf_btcoex_info is freed after the worker has been scheduled 
but before or during its execution. In this case, statements within 
the brcmf_btcoex_handler() worker — such as the container_of macro 
and subsequent dereferences of the brcmf_btcoex_info object will 
cause a use-after-free access. The following timeline illustrates
this scenario:

CPU0                            | CPU1
brcmf_btcoex_detach             | brcmf_btcoex_timerfunc
                                |   bt_local->timer_on = false;
  if (cfg->btcoex->timer_on)    |
    ...                         |
  cancel_work_sync();           |
  ...                           |   schedule_work(&bt_local->work); // Reschedule
                                |
  kfree(cfg->btcoex); // FREE   |   brcmf_btcoex_handler() // Worker
  /*                            |     btci = container_of(....); // USE
   The kfree() above could      |     ...
   also occur at any point      |     btci->vif; // USE
   during the worker's execution| 
   */                           |

I would like to submit a v2 patch to make the description clearer.

> > The following diagram illustrates this sequence of events:
> > 
> > cpu0                            cpu1
> > brcmf_btcoex_detach          |  brcmf_btcoex_timerfunc
> >                               |    bt_local->timer_on = false;
> >    if (cfg->btcoex->timer_on) |
> >      ...                      |
> >    cancel_work_sync();        |
> >    ...                        |    schedule_work() //reschedule
> >    kfree(cfg->btcoex);//free  |
> >                               |    brcmf_btcoex_handler() //worker
> >                               |    btci-> //use
> > 
> > To resolve this race condition, drop the conditional check and call
> > timer_shutdown_sync() directly. It can deactivate the timer reliably,
> > regardless of its current state. Once stopped, the timer_on state is
> > then set to false.
> 
> However, no reason to stop this patch from going in so...
> 
> Acked-by: Arend van Spriel <arend.vanspriel@...adcom.com>
> 
> > Fixes: 61730d4dfffc ("brcmfmac: support critical protocol API for DHCP")
> > Signed-off-by: Duoming Zhou <duoming@....edu.cn>
> > ---
> >   drivers/net/wireless/broadcom/brcm80211/brcmfmac/btcoex.c | 6 ++----
> >   1 file changed, 2 insertions(+), 4 deletions(-)

Best regards,
Duoming Zhou