From: Ahmad Fatoum <a.fatoum@pengutronix.de>
To: Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Cc: "linux-bluetooth@vger.kernel.org"
<linux-bluetooth@vger.kernel.org>,
Marcel Holtmann <marcel@holtmann.org>,
Pengutronix Kernel Team <kernel@pengutronix.de>,
"regressions@lists.linux.dev" <regressions@lists.linux.dev>
Subject: Re: [BUG] BLE device unpairing triggers kernel panic
Date: Mon, 16 May 2022 18:37:58 +0200 [thread overview]
Message-ID: <8d5c4724-d511-39b1-21d7-116c91cada45@pengutronix.de> (raw)
In-Reply-To: <CABBYNZ+zsuggTpaUSPsZKeL=qqvM1=sgMWzdWEqaS_oh6dhY2g@mail.gmail.com>
Hello Luiz,
On 14.05.22 01:52, Luiz Augusto von Dentz wrote:
> On Fri, May 13, 2022 at 1:14 PM Luiz Augusto von Dentz
> <luiz.dentz@gmail.com> wrote:
Thanks for the quick reply.
>> Hi Ahmad,
>>
>> On Fri, May 13, 2022 at 7:10 AM Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
>>>
>>> Hello,
>>>
>>> On Linux v5.18-rc5, I can reliably crash the kernel on the second (un)pairing
>>> with a customer's BLE device. I have bisected the issue and found two commits:
>>>
>>> - Commit 6cd29ec6ae5e ("Bluetooth: hci_sync: Wait for proper events when
>>> connecting LE") causes previously working pairing to time out, presumably
>>> because it keeps waiting for the wrong event.
>>
>> Can you describe in more details what is the second pairing, are you
>> pairing 2 devices concurrently? I recall someone for nxp having
>> similar problem, at least the traces look pretty similar, the problem
>> seems to be the expected event don't match the event the controller
>> send, in this case hci_le_enh_conn_complete_evt, so hci_event process
>> it and frees the hci_conn instead of first running the callback.
It's the same device. I set the host to pairable, then have the device
pair with the host. Then I unpair on the device and then redo the
same operation again. First one works. Second one fails triggering
the crash.
> Looks like my memory failed me on this one, the sync callback is run
> last so we shouldn't cleanup the hci_conn at that point, perhaps
> something like the following should fix the crash:
>
> diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
> index 0270e597c285..c1634af670b8 100644
> --- a/net/bluetooth/hci_event.c
> +++ b/net/bluetooth/hci_event.c
> @@ -5632,10 +5632,8 @@ static void le_conn_complete_evt(struct hci_dev
> *hdev, u8 status,
> status = HCI_ERROR_INVALID_PARAMETERS;
> }
>
> - if (status) {
> - hci_conn_failed(conn, status);
> + if (status)
> goto unlock;
> - }
Yes, this fixes the crash for me. Can you send a patch to that effect?
Feel free to add:
Tested-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
> if (conn->dst_type == ADDR_LE_DEV_PUBLIC)
> addr_type = BDADDR_LE_PUBLIC;
>
>>> - Commit a56a1138cbd8 ("Bluetooth: hci_sync: Fix not using conn_timeout")
>>> fixes, despite the title, what event is waited on. First Pairing works now,
>>> but the second pairing times out and crashes the kernel:
>>>
>>> [ 84.191684] Bluetooth: hci0: Opcode 0x200d failed: -110
>>> [ 84.230478] Bluetooth: hci0: request failed to create LE connection: err -110
>>> [ 84.237690] Unable to handle kernel read from unreadable memory at virtual address 0000000000000ca8
>
> That said the error -110 mean -ETIMEDOUT
Yes, this issue remains still. I feel better about my revert
knowing that the crash is fixed, but I'd like this regression
here fixed upstream as well. I'll try to collect some more
information and report back.
Cheers,
Ahmad
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
next prev parent reply other threads:[~2022-05-16 16:38 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-13 14:10 [BUG] BLE device unpairing triggers kernel panic Ahmad Fatoum
2022-05-13 20:14 ` Luiz Augusto von Dentz
2022-05-13 23:52 ` Luiz Augusto von Dentz
2022-05-13 23:57 ` Luiz Augusto von Dentz
2022-05-16 16:37 ` Ahmad Fatoum [this message]
2022-06-16 10:38 ` Ahmad Fatoum
2022-06-17 20:48 ` Luiz Augusto von Dentz
2022-06-20 10:06 ` Ahmad Fatoum
2022-06-20 20:18 ` Luiz Augusto von Dentz
2022-06-21 8:32 ` Ahmad Fatoum
2022-06-21 18:52 ` Luiz Augusto von Dentz
2022-06-24 12:53 ` Ahmad Fatoum
2022-06-24 19:59 ` Luiz Augusto von Dentz
2022-07-04 12:11 ` Thorsten Leemhuis
2022-07-07 5:45 ` Ahmad Fatoum
2022-08-17 10:24 ` Thorsten Leemhuis
2023-04-04 12:14 ` Linux regression tracking #update (Thorsten Leemhuis)
2023-04-04 12:17 ` Ahmad Fatoum
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8d5c4724-d511-39b1-21d7-116c91cada45@pengutronix.de \
--to=a.fatoum@pengutronix.de \
--cc=kernel@pengutronix.de \
--cc=linux-bluetooth@vger.kernel.org \
--cc=luiz.dentz@gmail.com \
--cc=marcel@holtmann.org \
--cc=regressions@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.