Re: [PATCH 2/2] Bluetooth: L2CAP: Clear request identifiers on incoming LE connections

[Greg KH]

On Mon, Nov 02, 2026 at 08:47:35PM +0800, Zhao Li wrote:
> Incoming LE and ECRED channels retain the peer's request identifier
> after an immediate response. The deferred LE response also leaves the
> identifier set, unlike the deferred ECRED response.
> 
> A later ECRED request can reuse that identifier and include an unrelated
> channel in its shared-response handling. That walk matches on the
> identifier alone, so an LE channel is selected too. If the old channel is
> closing, the checks can refuse the new connection. The check at request
> receipt rejects it with L2CAP_CR_LE_INVALID_PARAMS; the check before a
> deferred response returns L2CAP_CR_LE_AUTHORIZATION.
> 
> Store the identifier only when deferring the response, and clear it
> after sending the deferred LE response. Keep deferred ECRED identifiers
> until the shared response is sent, since a partially accepted group
> still needs them.
> 
> AI assistance was used.
> 
> Fixes: 27e2d4c8d28b ("Bluetooth: Add basic LE L2CAP connect request receiving support")
> Fixes: 15f02b910562 ("Bluetooth: L2CAP: Add initial code for Enhanced Credit Based Mode")
> Signed-off-by: Zhao Li <enderaoelyther@xxxxxxxxx>
> ---
> Built in patch order at W=1 with GCC 12.2 (x86_64 module, x86_64
> built-in and i386 module) and Clang 19.1.7 (x86_64 module). The x86_64
> module builds with both compilers also linked vmlinux and modules.
> Sparse checked l2cap_core.c with C=2 after each patch without
> diagnostics. Smatch reported the same pre-existing l2cap_chan_connect()
> diagnostic as the base; no cross-function database was used.
> 
> Coccinelle 1.3's use_after_iter rule found nothing in the changed
> functions. All changed functions were processed; five unchanged parser
> gaps also occur in the base. Hardware validation has not been run.
> 
> The two-patch QEMU/vhci arm kept all 445 established channels alive.
> In runs where new ECRED requests reused the identifier of a closing LE
> channel, the base and patch 1 alone refused 18 of 18 at each site:
> with L2CAP_CR_LE_INVALID_PARAMS at receipt, or with
> L2CAP_CR_LE_AUTHORIZATION in the deferred response. With this patch,
> all 18 completed with L2CAP_CR_LE_SUCCESS at both sites. Two further
> requests per run were refused identically on every kernel and are not
> counted. Partially accepted groups were not tested.
> 
> A KCSAN kernel with both patches, built without KASAN, ran the patch 1
> close-before workloads without data-race reports.
> 
>  net/bluetooth/l2cap_core.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
> index a21b2d70ad8a..0b6eb082f3f7 100644
> --- a/net/bluetooth/l2cap_core.c
> +++ b/net/bluetooth/l2cap_core.c
> @@ -3972,6 +3972,7 @@ void __l2cap_le_connect_rsp_defer(struct l2cap_chan *chan)
>  
>  	l2cap_send_cmd(conn, chan->ident, L2CAP_LE_CONN_RSP, sizeof(rsp),
>  		       &rsp);
> +	chan->ident = 0;
>  }
>  
>  static void l2cap_ecred_list_defer(struct l2cap_chan *chan, void *data)
> @@ -5311,10 +5312,10 @@ static int l2cap_le_connect_req(struct l2cap_conn *conn,
>  
>  	__set_chan_timer(chan, chan->ops->get_sndtimeo(chan));
>  
> -	chan->ident = cmd->ident;
>  	chan->mode = L2CAP_MODE_LE_FLOWCTL;
>  
>  	if (test_bit(FLAG_DEFER_SETUP, &chan->flags)) {
> +		chan->ident = cmd->ident;
>  		l2cap_state_change(chan, BT_CONNECT2);
>  		/* The following result value is actually not defined
>  		 * for LE CoC but we use it to let the function know
> @@ -5550,10 +5551,10 @@ static inline int l2cap_ecred_conn_req(struct l2cap_conn *conn,
>  
>  		__set_chan_timer(chan, chan->ops->get_sndtimeo(chan));
>  
> -		chan->ident = cmd->ident;
>  		chan->mode = L2CAP_MODE_EXT_FLOWCTL;
>  
>  		if (test_bit(FLAG_DEFER_SETUP, &chan->flags)) {
> +			chan->ident = cmd->ident;
>  			l2cap_state_change(chan, BT_CONNECT2);
>  			defer = true;
>  			chan->ops->defer(chan);
> -- 
> 2.56.0
> 
> 

Hi,

This is the friendly patch-bot of Greg Kroah-Hartman.  You have sent him
a patch that has triggered this response.  He used to manually respond
to these common problems, but in order to save his sanity (he kept
writing the same thing over and over, yet to different people), I was
created.  Hopefully you will not take offence and will fix the problem
in your patch and resubmit it so that it can be accepted into the Linux
kernel tree.

You are receiving this message because of the following common error(s)
as indicated below:

- You have marked a patch with a "Fixes:" tag for a commit that is in an
  older released kernel, yet you do not have a cc: stable line in the
  signed-off-by area at all, which means that the patch will not be
  applied to any older kernel releases.  To properly fix this, please
  follow the documented rules in the
  Documentation/process/stable-kernel-rules.rst file for how to resolve
  this.

If you wish to discuss this problem further, or you have questions about
how to resolve this issue, please feel free to respond to this email and
Greg will reply once he has dug out from the pending patches received
from other developers.

thanks,

greg k-h's patch email bot