[PATCH v7 RESEND 0/1] Bluetooth: L2CAP: Fix slab-use-after-free in l2cap_sock_cleanup_listen()

[PATCH v7 RESEND 0/1] Bluetooth: L2CAP: Fix slab-use-after-free in l2cap_sock_cleanup_listen()

[Siwei Zhang]

Hi Bluetooth maintainers,

A public patch covering the same UAF in l2cap_sock_cleanup_listen() was posted to linux-bluetooth on April 28 
by Safa Karakuş. v4 is here:

https://lore.kernel.org/linux-bluetooth/AS8P250MB079109F82C16BEDC4F9FE584EB372@AS8P250MB0791.EURP250.PROD.OUTLOOK.COM/

I thanks for Safa's report and patch. I already reported the same issue privately to the maintainers in 
April 11th. The public patch breaks the embargo and I would like to resend my patch here.

Safa's v4 closes the sk-lifetime hole (sock_hold inside bt_accept_dequeue) but does not take conn->lock around
l2cap_chan_close, so the conn->chan_l list-corruption race in my report is still open after it.

My patch closes both: it drops the parent sk_lock, acquires conn->lock → chan->lock in the established order
to serialize the chan_l mutation, and re-takes the parent sk_lock before returning.

Crash stack and C reproducers are available upon request, only for the maintainers.

Maintainers can also refer to the email thread [Bug] KASAN: slab-use-after-free Read in l2cap_security_cfm
sent to security@kernel.org on April 11th for more details.

Detailed Timeline:

April 11th: I privately reported the issue to the maintainers and security@kernel.org
April 12th: Patch v1
April 13th: Patch v2
April 13th: Patch v3
April 14th: Patch v4
April 15th: Patch v5
May 2nd: Patch v6
May 2nd: Patch v7
May 20th: Resend v7 with a cover letter

Best,
Siwei

Siwei Zhang (1):
  Bluetooth: L2CAP: Fix slab-use-after-free in
    l2cap_sock_cleanup_listen()

 net/bluetooth/l2cap_sock.c | 57 ++++++++++++++++++++++++++++++++------
 1 file changed, 49 insertions(+), 8 deletions(-)

-- 
2.54.0

[PATCH v7 RESEND 1/1] Bluetooth: L2CAP: Fix slab-use-after-free in l2cap_sock_cleanup_listen()

[Siwei Zhang]

l2cap_sock_cleanup_listen() calls l2cap_chan_close() without holding
conn->lock. A concurrent task iterating conn->chan_l under conn->lock
can access a channel that has been removed from the list and freed.
That can result in a slab-use-after-free.

Split cleanup into two phases. Drain the accept queue under the parent's
sk_lock onto a local list, taking a sock reference on each child so it
survives the lock drop. Then release the parent and close every drained
child under conn->lock + chan_lock, using
l2cap_chan_hold_unless_zero()/l2cap_conn_hold_unless_zero() to cope with
a teardown that has already started, and skipping any chan whose
->data has been cleared. Reacquire the parent's sk_lock at the end so
the caller's contract is preserved.

Noted that commit ab4eedb790ca
("Bluetooth: L2CAP: Fix corrupted list in hci_chan_del")
renamed chan_lock to lock in l2cap_conn.

Fixes: 3df91ea20e74 ("Bluetooth: Revert to mutexes from RCU list")
Cc: stable@kernel.org
Assisted-by: Claude:claude-opus-4-7
Signed-off-by: Siwei Zhang <oss@fourdim.xyz>
---
 net/bluetooth/l2cap_sock.c | 57 ++++++++++++++++++++++++++++++++------
 1 file changed, 49 insertions(+), 8 deletions(-)

diff --git a/net/bluetooth/l2cap_sock.c b/net/bluetooth/l2cap_sock.c
index 71e8c1b45bce..48b018991ced 100644
--- a/net/bluetooth/l2cap_sock.c
+++ b/net/bluetooth/l2cap_sock.c
@@ -1471,27 +1471,68 @@ static int l2cap_sock_release(struct socket *sock)
 static void l2cap_sock_cleanup_listen(struct sock *parent)
 {
 	struct sock *sk;
+	struct bt_sock *bs, *tmp;
+	LIST_HEAD(killable);
 
 	BT_DBG("parent %p state %s", parent,
 	       state_to_string(parent->sk_state));
 
-	/* Close not yet accepted channels */
+	/* Drain unaccepted children to a local list, pinning each so it
+	 * survives the parent lock-drop below.
+	 */
 	while ((sk = bt_accept_dequeue(parent, NULL))) {
-		struct l2cap_chan *chan = l2cap_pi(sk)->chan;
+		sock_hold(sk);
+		list_add_tail(&bt_sk(sk)->accept_q, &killable);
+	}
 
-		BT_DBG("child chan %p state %s", chan,
-		       state_to_string(chan->state));
+	/* l2cap_chan_close() must run under conn->lock, but the rx path
+	 * (l2cap_sock_new_connection_cb) takes conn->lock then lock_sock(parent),
+	 * so parent must be released before we close.  Draining the queue
+	 * first means a concurrent cleanup_listen() on the same parent finds
+	 * it empty and is a no-op.
+	 */
+	release_sock(parent);
+
+	list_for_each_entry_safe(bs, tmp, &killable, accept_q) {
+		struct l2cap_chan *chan;
+		struct l2cap_conn *conn;
+
+		sk = (struct sock *)bs;
+		list_del_init(&bs->accept_q);
+
+		chan = l2cap_chan_hold_unless_zero(l2cap_pi(sk)->chan);
+		if (!chan) {
+			sock_put(sk);
+			continue;
+		}
 
-		l2cap_chan_hold(chan);
+		l2cap_chan_lock(chan);
+		conn = l2cap_conn_hold_unless_zero(chan->conn);
+		l2cap_chan_unlock(chan);
+
+		if (conn)
+			mutex_lock(&conn->lock);
 		l2cap_chan_lock(chan);
 
-		__clear_chan_timer(chan);
-		l2cap_chan_close(chan, ECONNRESET);
-		l2cap_sock_kill(sk);
+		BT_DBG("child chan %p state %s", chan,
+		       state_to_string(chan->state));
+
+		if (chan->data) {
+			__clear_chan_timer(chan);
+			l2cap_chan_close(chan, ECONNRESET);
+			l2cap_sock_kill(sk);
+		}
 
 		l2cap_chan_unlock(chan);
+		if (conn) {
+			mutex_unlock(&conn->lock);
+			l2cap_conn_put(conn);
+		}
 		l2cap_chan_put(chan);
+		sock_put(sk);
 	}
+
+	lock_sock_nested(parent, L2CAP_NESTING_PARENT);
 }
 
 static struct l2cap_chan *l2cap_sock_new_connection_cb(struct l2cap_chan *chan)
-- 
2.54.0

RE: Bluetooth: L2CAP: Fix slab-use-after-free in l2cap_sock_cleanup_listen()

[bluez.test.bot]

[-- Attachment #1: Type: text/plain, Size: 1604 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=1098174

---Test result---

Test Summary:
CheckPatch                    PASS      0.68 seconds
GitLint                       FAIL      0.27 seconds
SubjectPrefix                 PASS      0.10 seconds
BuildKernel                   PASS      25.43 seconds
CheckAllWarning               PASS      27.91 seconds
CheckSparse                   PASS      26.60 seconds
BuildKernel32                 PASS      24.81 seconds
TestRunnerSetup               PASS      533.99 seconds
TestRunner_l2cap-tester       PASS      376.93 seconds
IncrementalBuild              PASS      23.53 seconds

Details
##############################
Test: GitLint - FAIL
Desc: Run gitlint
Output:
[v7,RESEND,1/1] Bluetooth: L2CAP: Fix slab-use-after-free in l2cap_sock_cleanup_listen()

WARNING: I3 - ignore-body-lines: gitlint will be switching from using Python regex 'match' (match beginning) to 'search' (match anywhere) semantics. Please review your ignore-body-lines.regex option accordingly. To remove this warning, set general.regex-style-search=True. More details: https://jorisroovers.github.io/gitlint/configuration/#regex-style-search
1: T1 Title exceeds max length (88>80): "[v7,RESEND,1/1] Bluetooth: L2CAP: Fix slab-use-after-free in l2cap_sock_cleanup_listen()"


https://github.com/bluez/bluetooth-next/pull/222

---
Regards,
Linux Bluetooth

Re: [PATCH v7 RESEND 0/1] Bluetooth: L2CAP: Fix slab-use-after-free in l2cap_sock_cleanup_listen()

[Luiz Augusto von Dentz]

Hi Siwei,

On Wed, May 20, 2026 at 12:39 PM Siwei Zhang <oss@fourdim.xyz> wrote:
>
> Hi Bluetooth maintainers,
>
> A public patch covering the same UAF in l2cap_sock_cleanup_listen() was posted to linux-bluetooth on April 28
> by Safa Karakuş. v4 is here:
>
> https://lore.kernel.org/linux-bluetooth/AS8P250MB079109F82C16BEDC4F9FE584EB372@AS8P250MB0791.EURP250.PROD.OUTLOOK.COM/
>
> I thanks for Safa's report and patch. I already reported the same issue privately to the maintainers in
> April 11th. The public patch breaks the embargo and I would like to resend my patch here.
>
> Safa's v4 closes the sk-lifetime hole (sock_hold inside bt_accept_dequeue) but does not take conn->lock around
> l2cap_chan_close, so the conn->chan_l list-corruption race in my report is still open after it.

Are your changes on top of Safa's though? That seems a lot cleaner to be honest.

> My patch closes both: it drops the parent sk_lock, acquires conn->lock → chan->lock in the established order
> to serialize the chan_l mutation, and re-takes the parent sk_lock before returning.

I rather have each issue handled separately though.

> Crash stack and C reproducers are available upon request, only for the maintainers.
>
> Maintainers can also refer to the email thread [Bug] KASAN: slab-use-after-free Read in l2cap_security_cfm
> sent to security@kernel.org on April 11th for more details.
>
> Detailed Timeline:
>
> April 11th: I privately reported the issue to the maintainers and security@kernel.org
> April 12th: Patch v1
> April 13th: Patch v2
> April 13th: Patch v3
> April 14th: Patch v4
> April 15th: Patch v5
> May 2nd: Patch v6
> May 2nd: Patch v7
> May 20th: Resend v7 with a cover letter
>
> Best,
> Siwei
>
> Siwei Zhang (1):
>   Bluetooth: L2CAP: Fix slab-use-after-free in
>     l2cap_sock_cleanup_listen()
>
>  net/bluetooth/l2cap_sock.c | 57 ++++++++++++++++++++++++++++++++------
>  1 file changed, 49 insertions(+), 8 deletions(-)
>
> --
> 2.54.0
>


-- 
Luiz Augusto von Dentz

Re: [PATCH v7 RESEND 0/1] Bluetooth: L2CAP: Fix slab-use-after-free in l2cap_sock_cleanup_listen()

[Siwei Zhang]

Hi Luiz,

On Wed, May 20, 2026, at 2:26 PM, Luiz Augusto von Dentz wrote:
> Hi Siwei,
>
> On Wed, May 20, 2026 at 12:39 PM Siwei Zhang <oss@fourdim.xyz> wrote:
>>
>> Hi Bluetooth maintainers,
>>
>> A public patch covering the same UAF in l2cap_sock_cleanup_listen() was posted to linux-bluetooth on April 28
>> by Safa Karakuş. v4 is here:
>>
>> https://lore.kernel.org/linux-bluetooth/AS8P250MB079109F82C16BEDC4F9FE584EB372@AS8P250MB0791.EURP250.PROD.OUTLOOK.COM/
>>
>> I thanks for Safa's report and patch. I already reported the same issue privately to the maintainers in
>> April 11th. The public patch breaks the embargo and I would like to resend my patch here.
>>
>> Safa's v4 closes the sk-lifetime hole (sock_hold inside bt_accept_dequeue) but does not take conn->lock around
>> l2cap_chan_close, so the conn->chan_l list-corruption race in my report is still open after it.
>
> Are your changes on top of Safa's though? That seems a lot cleaner to be honest.
>

My patch is not on the top of Safa's. The diff looks quite different.
I reported both the sk-lifetime UAF and the conn->chan_l list-corruption race
privately to the maintainers on April 11th. And patch shortly on April 12th.

>> My patch closes both: it drops the parent sk_lock, acquires conn->lock → chan->lock in the established order
>> to serialize the chan_l mutation, and re-takes the parent sk_lock before returning.
>
> I rather have each issue handled separately though.
>

I am happy to handle that separately.

Could I get a Reported-by on Safa's patch since I reported the underlying issue before the public post?

Reported-by: Siwei Zhang <oss@fourdim.xyz>

I'll send the conn->lock patch (drains accept queue to local list, drops parent sk_lock, acquires conn->lock -> chan_lock in
established order) as another patch shortly.

>> Crash stack and C reproducers are available upon request, only for the maintainers.
>>
>> Maintainers can also refer to the email thread [Bug] KASAN: slab-use-after-free Read in l2cap_security_cfm
>> sent to security@kernel.org on April 11th for more details.
>>
>> Detailed Timeline:
>>
>> April 11th: I privately reported the issue to the maintainers and security@kernel.org
>> April 12th: Patch v1
>> April 13th: Patch v2
>> April 13th: Patch v3
>> April 14th: Patch v4
>> April 15th: Patch v5
>> May 2nd: Patch v6
>> May 2nd: Patch v7
>> May 20th: Resend v7 with a cover letter
>>
>> Best,
>> Siwei
>>
>> Siwei Zhang (1):
>>   Bluetooth: L2CAP: Fix slab-use-after-free in
>>     l2cap_sock_cleanup_listen()
>>
>>  net/bluetooth/l2cap_sock.c | 57 ++++++++++++++++++++++++++++++++------
>>  1 file changed, 49 insertions(+), 8 deletions(-)
>>
>> --
>> 2.54.0
>>
>
>
> -- 
> Luiz Augusto von Dentz

Best,
Siwei

Re: [PATCH v7 RESEND 0/1] Bluetooth: L2CAP: Fix slab-use-after-free in l2cap_sock_cleanup_listen()

[Luiz Augusto von Dentz]

Hi Siwei,

On Wed, May 20, 2026 at 2:57 PM Siwei Zhang <oss@fourdim.xyz> wrote:
>
> Hi Luiz,
>
> On Wed, May 20, 2026, at 2:26 PM, Luiz Augusto von Dentz wrote:
> > Hi Siwei,
> >
> > On Wed, May 20, 2026 at 12:39 PM Siwei Zhang <oss@fourdim.xyz> wrote:
> >>
> >> Hi Bluetooth maintainers,
> >>
> >> A public patch covering the same UAF in l2cap_sock_cleanup_listen() was posted to linux-bluetooth on April 28
> >> by Safa Karakuş. v4 is here:
> >>
> >> https://lore.kernel.org/linux-bluetooth/AS8P250MB079109F82C16BEDC4F9FE584EB372@AS8P250MB0791.EURP250.PROD.OUTLOOK.COM/
> >>
> >> I thanks for Safa's report and patch. I already reported the same issue privately to the maintainers in
> >> April 11th. The public patch breaks the embargo and I would like to resend my patch here.
> >>
> >> Safa's v4 closes the sk-lifetime hole (sock_hold inside bt_accept_dequeue) but does not take conn->lock around
> >> l2cap_chan_close, so the conn->chan_l list-corruption race in my report is still open after it.
> >
> > Are your changes on top of Safa's though? That seems a lot cleaner to be honest.
> >
>
> My patch is not on the top of Safa's. The diff looks quite different.
> I reported both the sk-lifetime UAF and the conn->chan_l list-corruption race
> privately to the maintainers on April 11th. And patch shortly on April 12th.

I'm afraid it doesn't matter if you reported first or not, Safa's fix
is much easier to understand. However, there still seems to be an
issue of calling l2cap_chan_del without holding the conn->lock.

> >> My patch closes both: it drops the parent sk_lock, acquires conn->lock → chan->lock in the established order
> >> to serialize the chan_l mutation, and re-takes the parent sk_lock before returning.
> >
> > I rather have each issue handled separately though.
> >
>
> I am happy to handle that separately.
>
> Could I get a Reported-by on Safa's patch since I reported the underlying issue before the public post?
>
> Reported-by: Siwei Zhang <oss@fourdim.xyz>

You can do it yourself, just respond to the thread. Bonus points if
you add a Tested-by if it actually fixes part of the problem reported.

> I'll send the conn->lock patch (drains accept queue to local list, drops parent sk_lock, acquires conn->lock -> chan_lock in
> established order) as another patch shortly.

Don't quite like that solution though, we should be dropping locks we
didn't acquire on the same scope, besides it seem that was doing a lot
of malabarism, perhaps we could just schedule l2cap_chan_timeout with
something like this:

diff --git a/net/bluetooth/l2cap_sock.c b/net/bluetooth/l2cap_sock.c
index 4ed745a9c2cf..413b1c63602a 100644
--- a/net/bluetooth/l2cap_sock.c
+++ b/net/bluetooth/l2cap_sock.c
@@ -1529,8 +1529,11 @@ static void l2cap_sock_cleanup_listen(struct
sock *parent)
                       state_to_string(chan->state));

                l2cap_chan_lock(chan);
-               __clear_chan_timer(chan);
-               l2cap_chan_close(chan, ECONNRESET);
+               /* Since we cannot call l2cap_chan_close() without
+                * chan->conn, schedule its timer to trigger the close and
+                * cleanup of this channel.
+                */
+               __set_chan_timer(chan, 0);
                /* l2cap_conn_del() may already have killed this socket
                 * (it sets SOCK_DEAD); skip the duplicate to avoid a
                 * double sock_put()/l2cap_chan_put().

Or perhaps it needs to be conditional to having chan->conn since that
indicates l2cap_chan_del has not run yet, making it safe to use
__set_chan_timer.

Re: [PATCH v7 RESEND 0/1] Bluetooth: L2CAP: Fix slab-use-after-free in l2cap_sock_cleanup_listen()

[Siwei Zhang]

On Wed, May 20, 2026, at 3:40 PM, Luiz Augusto von Dentz wrote:
> Hi Siwei,
>
> On Wed, May 20, 2026 at 2:57 PM Siwei Zhang <oss@fourdim.xyz> wrote:
>>
>> Hi Luiz,
>>
>> On Wed, May 20, 2026, at 2:26 PM, Luiz Augusto von Dentz wrote:
>> > Hi Siwei,
>> >
>> > On Wed, May 20, 2026 at 12:39 PM Siwei Zhang <oss@fourdim.xyz> wrote:
>> >>
>> >> Hi Bluetooth maintainers,
>> >>
>> >> A public patch covering the same UAF in l2cap_sock_cleanup_listen() was posted to linux-bluetooth on April 28
>> >> by Safa Karakuş. v4 is here:
>> >>
>> >> https://lore.kernel.org/linux-bluetooth/AS8P250MB079109F82C16BEDC4F9FE584EB372@AS8P250MB0791.EURP250.PROD.OUTLOOK.COM/
>> >>
>> >> I thanks for Safa's report and patch. I already reported the same issue privately to the maintainers in
>> >> April 11th. The public patch breaks the embargo and I would like to resend my patch here.
>> >>
>> >> Safa's v4 closes the sk-lifetime hole (sock_hold inside bt_accept_dequeue) but does not take conn->lock around
>> >> l2cap_chan_close, so the conn->chan_l list-corruption race in my report is still open after it.
>> >
>> > Are your changes on top of Safa's though? That seems a lot cleaner to be honest.
>> >
>>
>> My patch is not on the top of Safa's. The diff looks quite different.
>> I reported both the sk-lifetime UAF and the conn->chan_l list-corruption race
>> privately to the maintainers on April 11th. And patch shortly on April 12th.
>
> I'm afraid it doesn't matter if you reported first or not, Safa's fix
> is much easier to understand. However, there still seems to be an
> issue of calling l2cap_chan_del without holding the conn->lock.
>
>> >> My patch closes both: it drops the parent sk_lock, acquires conn->lock → chan->lock in the established order
>> >> to serialize the chan_l mutation, and re-takes the parent sk_lock before returning.
>> >
>> > I rather have each issue handled separately though.
>> >
>>
>> I am happy to handle that separately.
>>
>> Could I get a Reported-by on Safa's patch since I reported the underlying issue before the public post?
>>
>> Reported-by: Siwei Zhang <oss@fourdim.xyz>
>
> You can do it yourself, just respond to the thread. Bonus points if
> you add a Tested-by if it actually fixes part of the problem reported.
>
>> I'll send the conn->lock patch (drains accept queue to local list, drops parent sk_lock, acquires conn->lock -> chan_lock in
>> established order) as another patch shortly.
>
> Don't quite like that solution though, we should be dropping locks we
> didn't acquire on the same scope, besides it seem that was doing a lot
> of malabarism, perhaps we could just schedule l2cap_chan_timeout with
> something like this:
>
> diff --git a/net/bluetooth/l2cap_sock.c b/net/bluetooth/l2cap_sock.c
> index 4ed745a9c2cf..413b1c63602a 100644
> --- a/net/bluetooth/l2cap_sock.c
> +++ b/net/bluetooth/l2cap_sock.c
> @@ -1529,8 +1529,11 @@ static void l2cap_sock_cleanup_listen(struct
> sock *parent)
>                        state_to_string(chan->state));
>
>                 l2cap_chan_lock(chan);
> -               __clear_chan_timer(chan);
> -               l2cap_chan_close(chan, ECONNRESET);
> +               /* Since we cannot call l2cap_chan_close() without
> +                * chan->conn, schedule its timer to trigger the close and
> +                * cleanup of this channel.
> +                */
> +               __set_chan_timer(chan, 0);
>                 /* l2cap_conn_del() may already have killed this socket
>                  * (it sets SOCK_DEAD); skip the duplicate to avoid a
>                  * double sock_put()/l2cap_chan_put().
>
> Or perhaps it needs to be conditional to having chan->conn since that
> indicates l2cap_chan_del has not run yet, making it safe to use
> __set_chan_timer.

Thanks, that is much cleaner. 

PATCH sent to https://lore.kernel.org/linux-bluetooth/20260520200611.3033410-1-oss@fourdim.xyz/

Best,
Siwei