[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <15f6b85f-b1ce-409a-a728-38a7223a7c6c@app.fastmail.com>
Date: Mon, 09 Oct 2023 22:08:01 +0200
From: "Arnd Bergmann" <arnd@...db.de>
To: "Kees Cook" <keescook@...omium.org>
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 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.
Arnd
Powered by blists - more mailing lists