linux-kernel - Re: [PATCH RESEND 2/2] Bluetooth: fix use-bdaddr-property quirk

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:   Fri, 2 Jun 2023 10:21:55 +0200
From:   Johan Hovold <johan@...nel.org>
To:     Marek Szyprowski <m.szyprowski@...sung.com>
Cc:     Johan Hovold <johan+linaro@...nel.org>,
        Marcel Holtmann <marcel@...tmann.org>,
        Johan Hedberg <johan.hedberg@...il.com>,
        Luiz Augusto von Dentz <luiz.dentz@...il.com>,
        Matthias Kaehlcke <mka@...omium.org>,
        linux-bluetooth@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH RESEND 2/2] Bluetooth: fix use-bdaddr-property quirk

On Fri, Jun 02, 2023 at 12:01:55AM +0200, Marek Szyprowski wrote:
> On 31.05.2023 11:04, Johan Hovold wrote:
> > Devices that lack persistent storage for the device address can indicate
> > this by setting the HCI_QUIRK_INVALID_BDADDR which causes the controller
> > to be marked as unconfigured until user space has set a valid address.
> >
> > The related HCI_QUIRK_USE_BDADDR_PROPERTY was later added to similarly
> > indicate that the device lacks a valid address but that one may be
> > specified in the devicetree.
> >
> > As is clear from commit 7a0e5b15ca45 ("Bluetooth: Add quirk for reading
> > BD_ADDR from fwnode property") that added and documented this quirk and
> > commits like de79a9df1692 ("Bluetooth: btqcomsmd: use
> > HCI_QUIRK_USE_BDADDR_PROPERTY"), the device address of controllers with
> > this flag should be treated as invalid until user space has had a chance
> > to configure the controller in case the devicetree property is missing.
> >
> > As it does not make sense to allow controllers with invalid addresses,
> > restore the original semantics, which also makes sure that the
> > implementation is consistent (e.g. get_missing_options() indicates that
> > the address must be set) and matches the documentation (including
> > comments in the code, such as, "In case any of them is set, the
> > controller has to start up as unconfigured.").
> >
> > Fixes: e668eb1e1578 ("Bluetooth: hci_core: Don't stop BT if the BD address missing in dts")
> > Signed-off-by: Johan Hovold <johan+linaro@...nel.org>
> 
> This patch has been recently merged to linux-next as commit 6ac517d8cf8b 
> ("Bluetooth: fix use-bdaddr-property quirk"). Unfortunately it breaks 
> bluetooth operation on my Raspberry Pi 3b+, 4b+ and Khadas VIM3 based 
> test systems.
> 
> Before this patch on Raspberry Pi 4b+:
> 
> root@...get:~# dmesg | grep hci0
> [   14.459292] Bluetooth: hci0: BCM: chip id 107
> [   14.464283] Bluetooth: hci0: BCM: features 0x2f
> [   14.470632] Bluetooth: hci0: BCM4345C0
> [   14.474483] Bluetooth: hci0: BCM4345C0 (003.001.025) build 0000
> [   14.487275] Bluetooth: hci0: BCM4345C0 'brcm/BCM4345C0.hcd' Patch
> [   15.347542] Bluetooth: hci0: BCM: features 0x2f
> [   15.354588] Bluetooth: hci0: BCM43455 37.4MHz Raspberry Pi 3+-0159
> [   15.361076] Bluetooth: hci0: BCM4345C0 (003.001.025) build 0290
> root@...get:~# hcitool dev
> Devices:
>          hci0    DC:A6:32:12:38:D1

Thanks for the report and sorry about the breakage.

Turns out that the Broadcom driver has so far been setting the
HCI_QUIRK_USE_BDADDR_PROPERTY also for devices such as yours which
already have a valid address.

I've sent a fix for the Broadcom driver here:

	https://lore.kernel.org/lkml/20230602081912.4708-1-johan+linaro@kernel.org

which should address this. Could you give it a try?

Johan