Received-SPF: pass (google.com: domain of linux-bluetooth-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) client-ip=2620:137:e000::3:3;
MIME-Version: 1.0
References: <20231009134826.1063869-1-arnd@kernel.org> <2abaad09-b6e0-4dd5-9796-939f20804865@app.fastmail.com>
 <202310090902.10ED782652@keescook> <73f552a4-4ff5-441a-a624-ddc34365742f@app.fastmail.com>
 <202310091246.ED5A2AFB21@keescook> <15f6b85f-b1ce-409a-a728-38a7223a7c6c@app.fastmail.com>
 <202310091310.F560494@keescook>
In-Reply-To: <202310091310.F560494@keescook>
From:   Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Date:   Mon, 9 Oct 2023 17:01:53 -0700
Message-ID: <CABBYNZJYYoseM04eWd+rRVmyS1YbssHxt9bowkX544VXGcZUeA@mail.gmail.com>
Subject: Re: [PATCH] Bluetooth: mark bacmp() and bacpy() as __always_inline
To:     Kees Cook <keescook@chromium.org>
Cc:     Arnd Bergmann <arnd@arndb.de>, Arnd Bergmann <arnd@kernel.org>,
        Marcel Holtmann <marcel@holtmann.org>,
        Johan Hedberg <johan.hedberg@gmail.com>,
        "David S . Miller" <davem@davemloft.net>,
        Eric Dumazet <edumazet@google.com>,
        Jakub Kicinski <kuba@kernel.org>,
        Paolo Abeni <pabeni@redhat.com>, Chun-Yi Lee <jlee@suse.com>,
        Luiz Augusto von Dentz <luiz.von.dentz@intel.com>,
        stable@vger.kernel.org, Iulia Tanasescu <iulia.tanasescu@nxp.com>,
        Wenjia Zhang <wenjia@linux.ibm.com>,
        linux-bluetooth@vger.kernel.org, Netdev <netdev@vger.kernel.org>,
        linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

Hi,

On Mon, Oct 9, 2023 at 1:15=E2=80=AFPM Kees Cook <keescook@chromium.org> wr=
ote:
>
> 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 =3D 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 aga=
inst
> >          * 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.

Perhaps we could something like:

#define bt_dev_bacmp(hdev, bdaddr) ((hdev) ? bacmp(&(hdev)->bdaddr,
bdaddr) : -EINVAL)

Or the fact that we test for hdev makes the compiler assume it could
NULL? If I recall correctly we did that because in some codepaths
there is actually no hdev to use so it is passed as NULL.

> --
> Kees Cook


--=20
Luiz Augusto von Dentz