linux-kernel - Re: [PATCH] Bluetooth: hci_qca: Set SSR triggered flags when SSR command is sent out

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:   Mon, 16 Aug 2021 18:07:43 +0200
From:   Marcel Holtmann <marcel@...tmann.org>
To:     Balakrishna Godavarthi <bgodavar@...eaurora.org>
Cc:     Johan Hedberg <johan.hedberg@...il.com>,
        Matthias Kaehlcke <mka@...omium.org>,
        open list <linux-kernel@...r.kernel.org>,
        "open list:BLUETOOTH SUBSYSTEM" <linux-bluetooth@...r.kernel.org>,
        Hemantg <hemantg@...eaurora.org>,
        MSM <linux-arm-msm@...r.kernel.org>, pharish@...eaurora.org,
        Rocky Liao <rjliao@...eaurora.org>, hbandi@...eaurora.org,
        abhishekpandit@...omium.org, mcchou@...omium.org
Subject: Re: [PATCH] Bluetooth: hci_qca: Set SSR triggered flags when SSR
 command is sent out

Hi Balakrishna,

> This change sets SSR triggered flags when QCA SSR command is sent to
> SoC. After the SSR command sent, driver discards the incoming data from
> the upper layers. This way will ensure to read full dumps from the
> BT SoC without any flow control issues due to excess of data receiving
> from the HOST in audio usecases.
> 
> Signed-off-by: Balakrishna Godavarthi <bgodavar@...eaurora.org>
> ---
> drivers/bluetooth/hci_qca.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
> 
> diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
> index 53deea2..5cbed6a 100644
> --- a/drivers/bluetooth/hci_qca.c
> +++ b/drivers/bluetooth/hci_qca.c
> @@ -69,6 +69,8 @@
> #define QCA_LAST_SEQUENCE_NUM		0xFFFF
> #define QCA_CRASHBYTE_PACKET_LEN	1096
> #define QCA_MEMDUMP_BYTE		0xFB
> +#define QCA_SSR_OPCODE			0xFC0C
> +#define QCA_SSR_PKT_LEN		5
> 
> enum qca_flags {
> 	QCA_IBS_DISABLED,
> @@ -871,6 +873,14 @@ static int qca_enqueue(struct hci_uart *hu, struct sk_buff *skb)
> 	/* Prepend skb with frame type */
> 	memcpy(skb_push(skb, 1), &hci_skb_pkt_type(skb), 1);
> 
> +	if (hci_skb_pkt_type(skb) == HCI_COMMAND_PKT &&
> +	    skb->len == QCA_SSR_PKT_LEN &&
> +	    hci_skb_opcode(skb) == QCA_SSR_OPCODE) {
> +		bt_dev_info(hu->hdev, "Triggering ssr");
> +		set_bit(QCA_SSR_TRIGGERED, &qca->flags);
> +		set_bit(QCA_MEMDUMP_COLLECTION, &qca->flags);
> +	}
> +

can we please stop hacking around by parsing opcodes in an enqueue function. Sounds like someone is injecting raw HCI vendor commands and then having a driver react to it.

Regards

Marcel