linux-kernel - Re: [PATCH] l2cap_core: automatically flushable packets aren't supported by LE-only devices

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] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 19 Nov 2014 07:01:42 +0900
From:	Marcel Holtmann <marcel@...tmann.org>
To:	Steven Walter <stevenrwalter@...il.com>
Cc:	linux-kernel <linux-kernel@...r.kernel.org>,
	BlueZ development <linux-bluetooth@...r.kernel.org>,
	"Gustavo F. Padovan" <gustavo@...ovan.org>,
	Johan Hedberg <johan.hedberg@...il.com>
Subject: Re: [PATCH] l2cap_core: automatically flushable packets aren't supported by LE-only devices

Hi Steven,

> The bluetooth spec states that automatically flushable packets may not
> be sent to a LE-only controller.  The code already supports
> non-automatically-flushable packets, but uses a bit in the controller
> feature field to determine whether to use them.  That bit is always zero
> for LE-only devices, so we need to check for the LE-only case explicitly.
> ---
> net/bluetooth/l2cap_core.c | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
> index 4af3821..29d9b9c 100644
> --- a/net/bluetooth/l2cap_core.c
> +++ b/net/bluetooth/l2cap_core.c
> @@ -764,7 +764,7 @@ static void l2cap_send_cmd(struct l2cap_conn *conn, u8 ident, u8 code, u16 len,
> 	if (!skb)
> 		return;
> 
> -	if (lmp_no_flush_capable(conn->hcon->hdev))
> +	if (lmp_no_flush_capable(conn->hcon->hdev) || !lmp_bredr_capable(conn->hcon->hdev))
> 		flags = ACL_START_NO_FLUSH;
> 	else
> 		flags = ACL_START;
> @@ -798,8 +798,9 @@ static void l2cap_do_send(struct l2cap_chan *chan, struct sk_buff *skb)
> 		return;
> 	}
> 
> -	if (!test_bit(FLAG_FLUSHABLE, &chan->flags) &&
> -	    lmp_no_flush_capable(hcon->hdev))
> +	if (!lmp_bredr_capable(hcon->hdev) ||
> +	    (!test_bit(FLAG_FLUSHABLE, &chan->flags) &&
> +	    lmp_no_flush_capable(hcon->hdev)))
> 		flags = ACL_START_NO_FLUSH;
> 	else
> 		flags = ACL_START;

I do not think doing it this way is correct. I am actually surprised that it using fine right now, but I assume that is because all dual-mode controllers also support non-flushable packets.

We should check the link type of the connection and if it is LE then we should always use non-flushable packets. The feature bits have really nothing to do with this. They only apply to the BR/EDR side of things. LE has its own supported feature bits.

Regards

Marcel

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/