public inbox for linux-bluetooth@vger.kernel.org
 help / color / mirror / Atom feed
* [PATCH BlueZ v1 0/1] Fix use-after-free in BAP broadcast cleanup
@ 2026-02-13 16:41 Sarveshwar Bajaj
  2026-02-13 16:41 ` [PATCH BlueZ v1 1/1] bap: Fix use-after-free in broadcast sink cleanup Sarveshwar Bajaj
  0 siblings, 1 reply; 6+ messages in thread
From: Sarveshwar Bajaj @ 2026-02-13 16:41 UTC (permalink / raw)
  To: linux-bluetooth, luiz.dentz
  Cc: vinit.mehta, sarveshwar.bajaj, devyani.godbole

This fixes a use-after-free crash when broadcast audio sources 
disconnect or undergo RPA rotation as reported in issue #1866.

The crash occurs because bap_data_free() was freeing streams before 
destroying the broadcast sink setups that still held references to them.

Tested with AddressSanitizer on latest 6.19 kernel with NXPs 
controller as broadcast sink and Samsung S23 broadcast source. 
No crashes observed with disconnect or RPA rotation after fix.


Sarveshwar Bajaj (1):
  bap: Fix use-after-free in broadcast sink cleanup

 profiles/audio/bap.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

-- 
2.51.0


^ permalink raw reply	[flat|nested] 6+ messages in thread

* [PATCH BlueZ v1 1/1] bap: Fix use-after-free in broadcast sink cleanup
  2026-02-13 16:41 [PATCH BlueZ v1 0/1] Fix use-after-free in BAP broadcast cleanup Sarveshwar Bajaj
@ 2026-02-13 16:41 ` Sarveshwar Bajaj
  2026-02-13 17:50   ` Fix use-after-free in BAP broadcast cleanup bluez.test.bot
  2026-02-13 18:16   ` [PATCH BlueZ v1 1/1] bap: Fix use-after-free in broadcast sink cleanup Pauli Virtanen
  0 siblings, 2 replies; 6+ messages in thread
From: Sarveshwar Bajaj @ 2026-02-13 16:41 UTC (permalink / raw)
  To: linux-bluetooth, luiz.dentz
  Cc: vinit.mehta, sarveshwar.bajaj, devyani.godbole

bap_data_free() was calling bt_bap_detach() before destroying
bcast_snks queue. bt_bap_detach() frees all streams but broadcast
sink setups in bcast_snks queue were still holding pointers to these
streams. When queue_destroy() calls setup_free() as its destructor,
it attempts to access these already-freed stream pointers, causing
a use-after-free.

Fix this by destroying the bcast_snks queue before calling
bt_bap_detach() and ensuring stream references are released while the
streams are still valid. This matches the cleanup order already used
for unicast.

Crash trace:
  AddressSanitizer: heap-use-after-free
  #0 bt_bap_stream_unlock src/shared/bap.c:6384
  #1 setup_free profiles/audio/bap.c:1123
  #2 queue_destroy src/shared/queue.c:60
  #3 bap_data_free profiles/audio/bap.c:210

https://github.com/bluez/bluez/issues/1866
---
 profiles/audio/bap.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/profiles/audio/bap.c b/profiles/audio/bap.c
index 90a978667..9108bf729 100644
--- a/profiles/audio/bap.c
+++ b/profiles/audio/bap.c
@@ -3822,6 +3822,12 @@ static void bap_bcast_remove(struct btd_service *service)
 		return;
 	}
 
+	/* Clean up before bis_remove and data_remove */
+	if (data->bcast_snks) {
+		queue_destroy(data->bcast_snks, setup_free);
+		data->bcast_snks = NULL;
+	}
+
 	bt_bap_bis_remove(data->bap);
 
 	bap_data_remove(data);
@@ -3938,6 +3944,11 @@ static int bap_bcast_disconnect(struct btd_service *service)
 		error("BAP service not handled by profile");
 		return -EINVAL;
 	}
+	/* Clean up broadcast sinks before detach (like unicast does) */
+	if (data->bcast_snks) {
+		queue_destroy(data->bcast_snks, setup_free);
+		data->bcast_snks = NULL;
+	}
 
 	bt_bap_detach(data->bap);
 
-- 
2.51.0


^ permalink raw reply related	[flat|nested] 6+ messages in thread

* RE: Fix use-after-free in BAP broadcast cleanup
  2026-02-13 16:41 ` [PATCH BlueZ v1 1/1] bap: Fix use-after-free in broadcast sink cleanup Sarveshwar Bajaj
@ 2026-02-13 17:50   ` bluez.test.bot
  2026-02-13 18:16   ` [PATCH BlueZ v1 1/1] bap: Fix use-after-free in broadcast sink cleanup Pauli Virtanen
  1 sibling, 0 replies; 6+ messages in thread
From: bluez.test.bot @ 2026-02-13 17:50 UTC (permalink / raw)
  To: linux-bluetooth, sarveshwar.bajaj

[-- Attachment #1: Type: text/plain, Size: 1262 bytes --]

This is automated email and please do not reply to this email!

Dear submitter,

Thank you for submitting the patches to the linux bluetooth mailing list.
This is a CI test results with your patch series:
PW Link:https://patchwork.kernel.org/project/bluetooth/list/?series=1053982

---Test result---

Test Summary:
CheckPatch                    PENDING   0.34 seconds
GitLint                       PENDING   0.44 seconds
BuildEll                      PASS      21.03 seconds
BluezMake                     PASS      657.97 seconds
MakeCheck                     PASS      18.76 seconds
MakeDistcheck                 PASS      246.97 seconds
CheckValgrind                 PASS      298.14 seconds
CheckSmatch                   PASS      363.40 seconds
bluezmakeextell               PASS      184.16 seconds
IncrementalBuild              PENDING   0.41 seconds
ScanBuild                     PASS      1035.30 seconds

Details
##############################
Test: CheckPatch - PENDING
Desc: Run checkpatch.pl script
Output:

##############################
Test: GitLint - PENDING
Desc: Run gitlint
Output:

##############################
Test: IncrementalBuild - PENDING
Desc: Incremental build with the patches in the series
Output:



---
Regards,
Linux Bluetooth


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH BlueZ v1 1/1] bap: Fix use-after-free in broadcast sink cleanup
  2026-02-13 16:41 ` [PATCH BlueZ v1 1/1] bap: Fix use-after-free in broadcast sink cleanup Sarveshwar Bajaj
  2026-02-13 17:50   ` Fix use-after-free in BAP broadcast cleanup bluez.test.bot
@ 2026-02-13 18:16   ` Pauli Virtanen
  2026-02-14 14:51     ` [EXT] " Sarveshwar Bajaj
  1 sibling, 1 reply; 6+ messages in thread
From: Pauli Virtanen @ 2026-02-13 18:16 UTC (permalink / raw)
  To: Sarveshwar Bajaj, linux-bluetooth, luiz.dentz
  Cc: vinit.mehta, devyani.godbole

Hi,

pe, 2026-02-13 kello 22:11 +0530, Sarveshwar Bajaj kirjoitti:
> bap_data_free() was calling bt_bap_detach() before destroying
> bcast_snks queue. bt_bap_detach() frees all streams but broadcast
> sink setups in bcast_snks queue were still holding pointers to these
> streams. When queue_destroy() calls setup_free() as its destructor,
> it attempts to access these already-freed stream pointers, causing
> a use-after-free.
> 
> Fix this by destroying the bcast_snks queue before calling
> bt_bap_detach() and ensuring stream references are released while the
> streams are still valid. This matches the cleanup order already used
> for unicast.
> 
> Crash trace:
>   AddressSanitizer: heap-use-after-free
>   #0 bt_bap_stream_unlock src/shared/bap.c:6384
>   #1 setup_free profiles/audio/bap.c:1123
>   #2 queue_destroy src/shared/queue.c:60
>   #3 bap_data_free profiles/audio/bap.c:210
> 
> https://github.com/bluez/bluez/issues/1866
> ---
>  profiles/audio/bap.c | 11 +++++++++++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/profiles/audio/bap.c b/profiles/audio/bap.c
> index 90a978667..9108bf729 100644
> --- a/profiles/audio/bap.c
> +++ b/profiles/audio/bap.c
> @@ -3822,6 +3822,12 @@ static void bap_bcast_remove(struct btd_service *service)
>  		return;
>  	}
>  
> +	/* Clean up before bis_remove and data_remove */
> +	if (data->bcast_snks) {
> +		queue_destroy(data->bcast_snks, setup_free);
> +		data->bcast_snks = NULL;

This probably should be done as in bap_data_free() since setup_free
also removes the entry from data->bcast_snks,

	struct queue *bcast_snks = data->bcast_snks;
	data->bcast_snks = NULL;
	queue_destroy(bcast_snks, setup_free);

as nested queue_destroy() -> queue_remove() is probably not safe.

> +	}
> +
>  	bt_bap_bis_remove(data->bap);
>  
>  	bap_data_remove(data);
> @@ -3938,6 +3944,11 @@ static int bap_bcast_disconnect(struct btd_service *service)
>  		error("BAP service not handled by profile");
>  		return -EINVAL;
>  	}
> +	/* Clean up broadcast sinks before detach (like unicast does) */
> +	if (data->bcast_snks) {
> +		queue_destroy(data->bcast_snks, setup_free);
> +		data->bcast_snks = NULL;
> +	}
>  
>  	bt_bap_detach(data->bap);
>  

-- 
Pauli Virtanen

^ permalink raw reply	[flat|nested] 6+ messages in thread

* RE: [EXT] Re: [PATCH BlueZ v1 1/1] bap: Fix use-after-free in broadcast sink cleanup
  2026-02-13 18:16   ` [PATCH BlueZ v1 1/1] bap: Fix use-after-free in broadcast sink cleanup Pauli Virtanen
@ 2026-02-14 14:51     ` Sarveshwar Bajaj
  0 siblings, 0 replies; 6+ messages in thread
From: Sarveshwar Bajaj @ 2026-02-14 14:51 UTC (permalink / raw)
  To: Pauli Virtanen, linux-bluetooth@vger.kernel.org,
	luiz.dentz@gmail.com
  Cc: Vinit Mehta, Devyani Godbole

Hi @Pauli,

Thanks for the review- good point about avoiding nested operations on the same queue during queue_destroy().
I've updated both bap_bcast_remove() and bap_bcast_disconnect() to:
- stash data->bcast_snks in a local,
- set data->bcast_snks = NULL up front,
- and only then call queue_destroy(bcast_snks, setup_free).
I'll send v2 using the safe cleanup pattern as you suggested, which avoids any nested queue operations by setting the field to NULL first.

-----Original Message-----
From: Pauli Virtanen <pav@iki.fi> 
Sent: 13 February 2026 23:47
To: Sarveshwar Bajaj <sarveshwar.bajaj@nxp.com>; linux-bluetooth@vger.kernel.org; luiz.dentz@gmail.com
Cc: Vinit Mehta <vinit.mehta@nxp.com>; Devyani Godbole <devyani.godbole@nxp.com>
Subject: [EXT] Re: [PATCH BlueZ v1 1/1] bap: Fix use-after-free in broadcast sink cleanup

[Some people who received this message don't often get email from pav@iki.fi. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]

Caution: This is an external email. Please take care when clicking links or opening attachments. When in doubt, report the message using the 'Report this email' button


Hi,

pe, 2026-02-13 kello 22:11 +0530, Sarveshwar Bajaj kirjoitti:
> bap_data_free() was calling bt_bap_detach() before destroying 
> bcast_snks queue. bt_bap_detach() frees all streams but broadcast sink 
> setups in bcast_snks queue were still holding pointers to these 
> streams. When queue_destroy() calls setup_free() as its destructor, it 
> attempts to access these already-freed stream pointers, causing a 
> use-after-free.
>
> Fix this by destroying the bcast_snks queue before calling
> bt_bap_detach() and ensuring stream references are released while the 
> streams are still valid. This matches the cleanup order already used 
> for unicast.
>
> Crash trace:
>   AddressSanitizer: heap-use-after-free
>   #0 bt_bap_stream_unlock src/shared/bap.c:6384
>   #1 setup_free profiles/audio/bap.c:1123
>   #2 queue_destroy src/shared/queue.c:60
>   #3 bap_data_free profiles/audio/bap.c:210
>
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> ub.com%2Fbluez%2Fbluez%2Fissues%2F1866&data=05%7C02%7Csarveshwar.bajaj
> %40nxp.com%7Ce6b54ca328ec4a27135b08de6b2c1380%7C686ea1d3bc2b4c6fa92cd9
> 9c5c301635%7C0%7C0%7C639066034219765336%7CUnknown%7CTWFpbGZsb3d8eyJFbX
> B0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIs
> IldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=9cnKU3urOQXDyDqUFWRVpKZ6iKTWsWUs2Z
> gswDbBG3k%3D&reserved=0
> ---
>  profiles/audio/bap.c | 11 +++++++++++
>  1 file changed, 11 insertions(+)
>
> diff --git a/profiles/audio/bap.c b/profiles/audio/bap.c index 
> 90a978667..9108bf729 100644
> --- a/profiles/audio/bap.c
> +++ b/profiles/audio/bap.c
> @@ -3822,6 +3822,12 @@ static void bap_bcast_remove(struct btd_service *service)
>               return;
>       }
>
> +     /* Clean up before bis_remove and data_remove */
> +     if (data->bcast_snks) {
> +             queue_destroy(data->bcast_snks, setup_free);
> +             data->bcast_snks = NULL;

This probably should be done as in bap_data_free() since setup_free also removes the entry from data->bcast_snks,

        struct queue *bcast_snks = data->bcast_snks;
        data->bcast_snks = NULL;
        queue_destroy(bcast_snks, setup_free);

as nested queue_destroy() -> queue_remove() is probably not safe.

> +     }
> +
>       bt_bap_bis_remove(data->bap);
>
>       bap_data_remove(data);
> @@ -3938,6 +3944,11 @@ static int bap_bcast_disconnect(struct btd_service *service)
>               error("BAP service not handled by profile");
>               return -EINVAL;
>       }
> +     /* Clean up broadcast sinks before detach (like unicast does) */
> +     if (data->bcast_snks) {
> +             queue_destroy(data->bcast_snks, setup_free);
> +             data->bcast_snks = NULL;
> +     }
>
>       bt_bap_detach(data->bap);
>

--
Pauli Virtanen

^ permalink raw reply	[flat|nested] 6+ messages in thread

* RE: Fix use-after-free in BAP broadcast cleanup
  2026-02-14 15:36 [PATCH BlueZ v2 " Sarveshwar Bajaj
@ 2026-02-14 16:34 ` bluez.test.bot
  0 siblings, 0 replies; 6+ messages in thread
From: bluez.test.bot @ 2026-02-14 16:34 UTC (permalink / raw)
  To: linux-bluetooth, sarveshwar.bajaj

[-- Attachment #1: Type: text/plain, Size: 1262 bytes --]

This is automated email and please do not reply to this email!

Dear submitter,

Thank you for submitting the patches to the linux bluetooth mailing list.
This is a CI test results with your patch series:
PW Link:https://patchwork.kernel.org/project/bluetooth/list/?series=1054177

---Test result---

Test Summary:
CheckPatch                    PENDING   0.45 seconds
GitLint                       PENDING   0.38 seconds
BuildEll                      PASS      20.91 seconds
BluezMake                     PASS      651.67 seconds
MakeCheck                     PASS      18.79 seconds
MakeDistcheck                 PASS      248.06 seconds
CheckValgrind                 PASS      300.04 seconds
CheckSmatch                   PASS      361.86 seconds
bluezmakeextell               PASS      185.00 seconds
IncrementalBuild              PENDING   0.41 seconds
ScanBuild                     PASS      1034.35 seconds

Details
##############################
Test: CheckPatch - PENDING
Desc: Run checkpatch.pl script
Output:

##############################
Test: GitLint - PENDING
Desc: Run gitlint
Output:

##############################
Test: IncrementalBuild - PENDING
Desc: Incremental build with the patches in the series
Output:



---
Regards,
Linux Bluetooth


^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2026-02-14 16:34 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-02-13 16:41 [PATCH BlueZ v1 0/1] Fix use-after-free in BAP broadcast cleanup Sarveshwar Bajaj
2026-02-13 16:41 ` [PATCH BlueZ v1 1/1] bap: Fix use-after-free in broadcast sink cleanup Sarveshwar Bajaj
2026-02-13 17:50   ` Fix use-after-free in BAP broadcast cleanup bluez.test.bot
2026-02-13 18:16   ` [PATCH BlueZ v1 1/1] bap: Fix use-after-free in broadcast sink cleanup Pauli Virtanen
2026-02-14 14:51     ` [EXT] " Sarveshwar Bajaj
  -- strict thread matches above, loose matches on Subject: below --
2026-02-14 15:36 [PATCH BlueZ v2 " Sarveshwar Bajaj
2026-02-14 16:34 ` Fix use-after-free in BAP broadcast cleanup bluez.test.bot

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox