linux-kernel - Re: [PATCH] Bluetooth: mark bacmp() and bacpy() as __always

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <202310091310.F560494@keescook>
Date:   Mon, 9 Oct 2023 13:15:32 -0700
From:   Kees Cook <keescook@...omium.org>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     Arnd Bergmann <arnd@...nel.org>,
        Marcel Holtmann <marcel@...tmann.org>,
        Johan Hedberg <johan.hedberg@...il.com>,
        Luiz Augusto von Dentz <luiz.dentz@...il.com>,
        "David S . Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>, Chun-Yi Lee <jlee@...e.com>,
        Luiz Augusto von Dentz <luiz.von.dentz@...el.com>,
        stable@...r.kernel.org, Iulia Tanasescu <iulia.tanasescu@....com>,
        Wenjia Zhang <wenjia@...ux.ibm.com>,
        linux-bluetooth@...r.kernel.org, Netdev <netdev@...r.kernel.org>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Bluetooth: mark bacmp() and bacpy() as __always_inline

On Mon, Oct 09, 2023 at 10:08:01PM +0200, Arnd Bergmann wrote:
> On Mon, Oct 9, 2023, at 21:48, Kees Cook wrote:
> > On Mon, Oct 09, 2023 at 08:23:08PM +0200, Arnd Bergmann wrote:
> >> On Mon, Oct 9, 2023, at 18:02, Kees Cook wrote:
> >> > On Mon, Oct 09, 2023 at 05:36:55PM +0200, Arnd Bergmann wrote:
> >> >> On Mon, Oct 9, 2023, at 15:48, Arnd Bergmann wrote:
> >> >> 
> >> >> Sorry, I have to retract this, something went wrong on my
> >> >> testing and I now see the same problem in some configs regardless
> >> >> of whether the patch is applied or not.
> >> >
> >> > Perhaps turn them into macros instead?
> >> 
> >> I just tried that and still see the problem even with the macro,
> >> so whatever gcc is doing must be a different issue. Maybe it
> >> has correctly found a codepath that triggers this?
> >> 
> >> If you are able to help debug the issue better,
> >> see these defconfigs for examples:
> >> 
> >> https://pastebin.com/raw/pC8Lnrn2
> >> https://pastebin.com/raw/yb965unC
> >
> > This seems like a GCC bug. It is complaining about &hdev->bdaddr for
> > some reason. This silences it:
> >
> > -	if (!bacmp(&hdev->bdaddr, &ev->bdaddr)) {
> > +	a = hdev->bdaddr;
> > +	if (!bacmp(&a, &ev->bdaddr)) {
> 
> Right, I see this addresses all instances. I tried another thing
> and this also seems to address them for me:
> 
> --- a/net/bluetooth/hci_event.c
> +++ b/net/bluetooth/hci_event.c
> @@ -3273,7 +3273,7 @@ static void hci_conn_request_evt(struct hci_dev *hdev, void *data,
>         /* Reject incoming connection from device with same BD ADDR against
>          * CVE-2020-26555
>          */
> -       if (!bacmp(&hdev->bdaddr, &ev->bdaddr)) {
> +       if (hdev && !bacmp(&hdev->bdaddr, &ev->bdaddr)) {
>                 bt_dev_dbg(hdev, "Reject connection with same BD_ADDR %pMR\n",
>                            &ev->bdaddr);
>                 hci_reject_conn(hdev, &ev->bdaddr);
> 
> and also this one does the trick:
> 
> --- a/include/net/bluetooth/bluetooth.h
> +++ b/include/net/bluetooth/bluetooth.h
> @@ -266,7 +266,7 @@ void bt_err_ratelimited(const char *fmt, ...);
>  #define BT_DBG(fmt, ...)       pr_debug(fmt "\n", ##__VA_ARGS__)
>  #endif
>  
> -#define bt_dev_name(hdev) ((hdev) ? (hdev)->name : "null")
> +#define bt_dev_name(hdev) ((hdev)->name)
>  
>  #define bt_dev_info(hdev, fmt, ...)                            \
>         BT_INFO("%s: " fmt, bt_dev_name(hdev), ##__VA_ARGS__)
> 
> So what is actually going on is that the bt_dev_dbg() introduces
> the idea that hdev might be NULL because of the check.

Oh thank you for finding that. Yeah, it looked to me like it thought
hdev was NULL, but I couldn't find where. :)

I think the best work-around here is your "hdev && " addition.

-- 
Kees Cook