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: diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c index 6f4409b4c364..509e86b36576 100644 --- a/net/bluetooth/hci_event.c +++ b/net/bluetooth/hci_event.c @@ -3266,6 +3266,7 @@ static void hci_conn_request_evt(struct hci_dev *hdev, void *data, int mask = hdev->link_mode; struct inquiry_entry *ie; struct hci_conn *conn; + bdaddr_t a; __u8 flags = 0; bt_dev_dbg(hdev, "bdaddr %pMR type 0x%x", &ev->bdaddr, ev->link_type); @@ -3273,7 +3274,8 @@ 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)) { + a = hdev->bdaddr; + if (!bacmp(&a, &ev->bdaddr)) { bt_dev_dbg(hdev, "Reject connection with same BD_ADDR %pMR\n", &ev->bdaddr); hci_reject_conn(hdev, &ev->bdaddr); :( -- Kees Cook
