Hi, On Mon, Oct 9, 2023 at 1:15 PM Kees Cook <keescook@xxxxxxxxxxxx> wrote: > > 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. 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 -- Luiz Augusto von Dentz
