[PATCH v3] Bluetooth: L2CAP: Reject signalling responses in invalid states

[PATCH v3] Bluetooth: L2CAP: Reject signalling responses in invalid states

[Siwei Zhang]

A peer can send configuration messages while an
incoming channel is in BT_CONNECT2, before the
security or deferred accept gate has completed. A
configuration response can then promote the channel
to BT_CONNECTED. Configuration responses can also
act on channels that are closing, and a late connection
response can move a disconnecting channel back to
BT_CONFIG.

Accept connection responses only while waiting in
BT_CONNECT. Answer configuration requests in
BT_CONNECT2, but defer our own request until
BT_CONFIG so configuration cannot complete before
the gate. Ignore configuration responses outside
BT_CONFIG and BT_CONNECTED, and only complete
configuration in BT_CONFIG.

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Siwei Zhang <oss@fourdim.xyz>
---
v3:
  - git lint on comments
v2: https://lore.kernel.org/linux-bluetooth/20260929154219.2366060-1-oss@fourdim.xyz/
  - resolve the patch conflict
v1: https://lore.kernel.org/linux-bluetooth/20260928173324.1837653-1-oss@fourdim.xyz/

 net/bluetooth/l2cap_core.c | 20 +++++++++++++++++++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
index 49a998804908..cb4ec42f99e3 100644
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -4438,6 +4438,10 @@ static int l2cap_connect_create_rsp(struct l2cap_conn *conn,
 
 	lockdep_assert_held(&chan->conn->lock);
 
+	/* Ignore a late response after the channel has left BT_CONNECT. */
+	if (chan->state != BT_CONNECT)
+		goto done;
+
 	switch (result) {
 	case L2CAP_CR_SUCCESS:
 		if (__l2cap_get_chan_by_dcid(conn, dcid)) {
@@ -4467,6 +4471,7 @@ static int l2cap_connect_create_rsp(struct l2cap_conn *conn,
 		break;
 	}
 
+done:
 	l2cap_chan_unlock(chan);
 	l2cap_chan_put(chan);
 
@@ -4604,7 +4609,13 @@ static inline int l2cap_config_req(struct l2cap_conn *conn,
 		goto unlock;
 	}
 
-	if (!test_and_set_bit(CONF_REQ_SENT, &chan->conf_state)) {
+	/* A channel in BT_CONNECT2 has not passed security or userspace
+	 * accept yet. Answer the peer's request, but hold our own until
+	 * the channel reaches BT_CONFIG: the CONNECT2 -> CONFIG sites send
+	 * it. Connected channels may also need to reconfigure.
+	 */
+	if ((chan->state == BT_CONFIG || chan->state == BT_CONNECTED) &&
+	    !test_and_set_bit(CONF_REQ_SENT, &chan->conf_state)) {
 		u8 buf[64];
 		l2cap_send_cmd(conn, l2cap_get_ident(conn), L2CAP_CONF_REQ,
 			       l2cap_build_conf_req(chan, buf, sizeof(buf)), buf);
@@ -4657,6 +4668,10 @@ static inline int l2cap_config_rsp(struct l2cap_conn *conn,
 
 	lockdep_assert_held(&chan->conn->lock);
 
+	/* Connected channels may also receive reconfiguration responses. */
+	if (chan->state != BT_CONFIG && chan->state != BT_CONNECTED)
+		goto done;
+
 	switch (result) {
 	case L2CAP_CONF_SUCCESS:
 		l2cap_conf_rfc_get(chan, rsp->data, len);
@@ -4724,6 +4739,9 @@ static inline int l2cap_config_rsp(struct l2cap_conn *conn,
 	if (test_bit(CONF_OUTPUT_DONE, &chan->conf_state)) {
 		set_default_fcs(chan);
 
+		if (chan->state != BT_CONFIG)
+			goto done;
+
 		if (chan->mode == L2CAP_MODE_ERTM ||
 		    chan->mode == L2CAP_MODE_STREAMING)
 			err = l2cap_ertm_init(chan);
-- 
2.55.0

Re: [PATCH v3] Bluetooth: L2CAP: Reject signalling responses in invalid states

[Luiz Augusto von Dentz]

Hi Siwei,

On Wed, Oct 7, 2026 at 10:47 AM Siwei Zhang <oss@fourdim.xyz> wrote:
>
> A peer can send configuration messages while an
> incoming channel is in BT_CONNECT2, before the
> security or deferred accept gate has completed. A
> configuration response can then promote the channel
> to BT_CONNECTED. Configuration responses can also
> act on channels that are closing, and a late connection
> response can move a disconnecting channel back to
> BT_CONFIG.
>
> Accept connection responses only while waiting in
> BT_CONNECT. Answer configuration requests in
> BT_CONNECT2, but defer our own request until
> BT_CONFIG so configuration cannot complete before
> the gate. Ignore configuration responses outside
> BT_CONFIG and BT_CONNECTED, and only complete
> configuration in BT_CONFIG.
>
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Cc: stable@vger.kernel.org
> Assisted-by: Claude:claude-opus-5-5
> Signed-off-by: Siwei Zhang <oss@fourdim.xyz>
> ---
> v3:
>   - git lint on comments
> v2: https://lore.kernel.org/linux-bluetooth/20260929154219.2366060-1-oss@fourdim.xyz/
>   - resolve the patch conflict
> v1: https://lore.kernel.org/linux-bluetooth/20260928173324.1837653-1-oss@fourdim.xyz/
>
>  net/bluetooth/l2cap_core.c | 20 +++++++++++++++++++-
>  1 file changed, 19 insertions(+), 1 deletion(-)
>
> diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
> index 49a998804908..cb4ec42f99e3 100644
> --- a/net/bluetooth/l2cap_core.c
> +++ b/net/bluetooth/l2cap_core.c
> @@ -4438,6 +4438,10 @@ static int l2cap_connect_create_rsp(struct l2cap_conn *conn,
>
>         lockdep_assert_held(&chan->conn->lock);
>
> +       /* Ignore a late response after the channel has left BT_CONNECT. */
> +       if (chan->state != BT_CONNECT)
> +               goto done;
> +
>         switch (result) {
>         case L2CAP_CR_SUCCESS:
>                 if (__l2cap_get_chan_by_dcid(conn, dcid)) {
> @@ -4467,6 +4471,7 @@ static int l2cap_connect_create_rsp(struct l2cap_conn *conn,
>                 break;
>         }
>
> +done:
>         l2cap_chan_unlock(chan);
>         l2cap_chan_put(chan);
>
> @@ -4604,7 +4609,13 @@ static inline int l2cap_config_req(struct l2cap_conn *conn,
>                 goto unlock;
>         }
>
> -       if (!test_and_set_bit(CONF_REQ_SENT, &chan->conf_state)) {
> +       /* A channel in BT_CONNECT2 has not passed security or userspace
> +        * accept yet. Answer the peer's request, but hold our own until
> +        * the channel reaches BT_CONFIG: the CONNECT2 -> CONFIG sites send
> +        * it. Connected channels may also need to reconfigure.
> +        */
> +       if ((chan->state == BT_CONFIG || chan->state == BT_CONNECTED) &&
> +           !test_and_set_bit(CONF_REQ_SENT, &chan->conf_state)) {
>                 u8 buf[64];
>                 l2cap_send_cmd(conn, l2cap_get_ident(conn), L2CAP_CONF_REQ,
>                                l2cap_build_conf_req(chan, buf, sizeof(buf)), buf);
> @@ -4657,6 +4668,10 @@ static inline int l2cap_config_rsp(struct l2cap_conn *conn,
>
>         lockdep_assert_held(&chan->conn->lock);
>
> +       /* Connected channels may also receive reconfiguration responses. */
> +       if (chan->state != BT_CONFIG && chan->state != BT_CONNECTED)
> +               goto done;
> +
>         switch (result) {
>         case L2CAP_CONF_SUCCESS:
>                 l2cap_conf_rfc_get(chan, rsp->data, len);
> @@ -4724,6 +4739,9 @@ static inline int l2cap_config_rsp(struct l2cap_conn *conn,
>         if (test_bit(CONF_OUTPUT_DONE, &chan->conf_state)) {
>                 set_default_fcs(chan);
>
> +               if (chan->state != BT_CONFIG)
> +                       goto done;
> +
>                 if (chan->mode == L2CAP_MODE_ERTM ||
>                     chan->mode == L2CAP_MODE_STREAMING)
>                         err = l2cap_ertm_init(chan);
> --
> 2.55.0

Sashiko flagged a problem with these changes:

https://sashiko.dev/#/patchset/20261007144717.3832330-1-oss%40fourdim.xyz

-- 
Luiz Augusto von Dentz

Re: [PATCH v3] Bluetooth: L2CAP: Reject signalling responses in invalid states

[Siwei Zhang]

On Wed, Oct 7, 2026, at 11:49 AM, Luiz Augusto von Dentz wrote:
> Hi Siwei,
>
> On Wed, Oct 7, 2026 at 10:47 AM Siwei Zhang <oss@fourdim.xyz> wrote:
>>
>> A peer can send configuration messages while an
>> incoming channel is in BT_CONNECT2, before the
>> security or deferred accept gate has completed. A
>> configuration response can then promote the channel
>> to BT_CONNECTED. Configuration responses can also
>> act on channels that are closing, and a late connection
>> response can move a disconnecting channel back to
>> BT_CONFIG.
>>
>> Accept connection responses only while waiting in
>> BT_CONNECT. Answer configuration requests in
>> BT_CONNECT2, but defer our own request until
>> BT_CONFIG so configuration cannot complete before
>> the gate. Ignore configuration responses outside
>> BT_CONFIG and BT_CONNECTED, and only complete
>> configuration in BT_CONFIG.
>>
>> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
>> Cc: stable@vger.kernel.org
>> Assisted-by: Claude:claude-opus-5-5
>> Signed-off-by: Siwei Zhang <oss@fourdim.xyz>
>> ---
>> v3:
>>   - git lint on comments
>> v2: https://lore.kernel.org/linux-bluetooth/20260929154219.2366060-1-oss@fourdim.xyz/
>>   - resolve the patch conflict
>> v1: https://lore.kernel.org/linux-bluetooth/20260928173324.1837653-1-oss@fourdim.xyz/
>>
>>  net/bluetooth/l2cap_core.c | 20 +++++++++++++++++++-
>>  1 file changed, 19 insertions(+), 1 deletion(-)
>>
>> diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
>> index 49a998804908..cb4ec42f99e3 100644
>> --- a/net/bluetooth/l2cap_core.c
>> +++ b/net/bluetooth/l2cap_core.c
>> @@ -4438,6 +4438,10 @@ static int l2cap_connect_create_rsp(struct l2cap_conn *conn,
>>
>>         lockdep_assert_held(&chan->conn->lock);
>>
>> +       /* Ignore a late response after the channel has left BT_CONNECT. */
>> +       if (chan->state != BT_CONNECT)
>> +               goto done;
>> +
>>         switch (result) {
>>         case L2CAP_CR_SUCCESS:
>>                 if (__l2cap_get_chan_by_dcid(conn, dcid)) {
>> @@ -4467,6 +4471,7 @@ static int l2cap_connect_create_rsp(struct l2cap_conn *conn,
>>                 break;
>>         }
>>
>> +done:
>>         l2cap_chan_unlock(chan);
>>         l2cap_chan_put(chan);
>>
>> @@ -4604,7 +4609,13 @@ static inline int l2cap_config_req(struct l2cap_conn *conn,
>>                 goto unlock;
>>         }
>>
>> -       if (!test_and_set_bit(CONF_REQ_SENT, &chan->conf_state)) {
>> +       /* A channel in BT_CONNECT2 has not passed security or userspace
>> +        * accept yet. Answer the peer's request, but hold our own until
>> +        * the channel reaches BT_CONFIG: the CONNECT2 -> CONFIG sites send
>> +        * it. Connected channels may also need to reconfigure.
>> +        */
>> +       if ((chan->state == BT_CONFIG || chan->state == BT_CONNECTED) &&
>> +           !test_and_set_bit(CONF_REQ_SENT, &chan->conf_state)) {
>>                 u8 buf[64];
>>                 l2cap_send_cmd(conn, l2cap_get_ident(conn), L2CAP_CONF_REQ,
>>                                l2cap_build_conf_req(chan, buf, sizeof(buf)), buf);
>> @@ -4657,6 +4668,10 @@ static inline int l2cap_config_rsp(struct l2cap_conn *conn,
>>
>>         lockdep_assert_held(&chan->conn->lock);
>>
>> +       /* Connected channels may also receive reconfiguration responses. */
>> +       if (chan->state != BT_CONFIG && chan->state != BT_CONNECTED)
>> +               goto done;
>> +
>>         switch (result) {
>>         case L2CAP_CONF_SUCCESS:
>>                 l2cap_conf_rfc_get(chan, rsp->data, len);
>> @@ -4724,6 +4739,9 @@ static inline int l2cap_config_rsp(struct l2cap_conn *conn,
>>         if (test_bit(CONF_OUTPUT_DONE, &chan->conf_state)) {
>>                 set_default_fcs(chan);
>>
>> +               if (chan->state != BT_CONFIG)
>> +                       goto done;
>> +
>>                 if (chan->mode == L2CAP_MODE_ERTM ||
>>                     chan->mode == L2CAP_MODE_STREAMING)
>>                         err = l2cap_ertm_init(chan);
>> --
>> 2.55.0
>
> Sashiko flagged a problem with these changes:
>
> https://sashiko.dev/#/patchset/20261007144717.3832330-1-oss%40fourdim.xyz
>

Hi Luiz,

Thank you for pointing this out. It is a valid bug.

That bug is already reachable without this patch.

For example, line 4719 l2cap_config_rsp in l2cap_core.c :

	if (flags & L2CAP_CONF_FLAG_CONTINUATION)
		goto done;

This line, which is just above my change, skips init as well.

I will send another patch to patch it because the fix will happen in
another function l2cap_parse_conf_rsp which is completely irrelevant.

Best,
Siwei

> -- 
> Luiz Augusto von Dentz

Re: [PATCH v3] Bluetooth: L2CAP: Reject signalling responses in invalid states

[patchwork-bot+bluetooth]

Hello:

This patch was applied to bluetooth/bluetooth-next.git (master)
by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:

On Wed,  7 Oct 2026 10:47:10 -0400 you wrote:
> A peer can send configuration messages while an
> incoming channel is in BT_CONNECT2, before the
> security or deferred accept gate has completed. A
> configuration response can then promote the channel
> to BT_CONNECTED. Configuration responses can also
> act on channels that are closing, and a late connection
> response can move a disconnecting channel back to
> BT_CONFIG.
> 
> [...]

Here is the summary with links:
  - [v3] Bluetooth: L2CAP: Reject signalling responses in invalid states
    https://git.kernel.org/bluetooth/bluetooth-next/c/0ff5a6d955bd

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html