Re: [PATCH v3] Bluetooth: call lock_sock() outside of spinlock section
From: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Date: 2021-07-22 05:16:39
Also in:
netdev
On 2021/07/22 13:47, LinMa wrote:
quoted hunk ↗ jump to hunk
Hi Tetsuo, Just find out another interesting function: sock_owned_by_user(). (I am just a noob of kernel locks) Hence I think the following patch has the same 'effect' as the old patch e305509e678b3 ("Bluetooth: use correct lock to prevent UAF of hdev object")diff --git a/net/bluetooth/hci_sock.c b/net/bluetooth/hci_sock.c index b04a5a02ecf3..0cc4b88daa96 100644 --- a/net/bluetooth/hci_sock.c +++ b/net/bluetooth/hci_sock.c@@ -762,7 +762,11 @@ void hci_sock_dev_event(struct hci_dev *hdev, int event) /* Detach sockets from device */ read_lock(&hci_sk_list.lock); sk_for_each(sk, &hci_sk_list.head) { - lock_sock(sk); + bh_lock_sock_nested(sk); +busywait: + if (sock_owned_by_user(sk)) + goto busywait; + if (hci_pi(sk)->hdev == hdev) { hci_pi(sk)->hdev = NULL; sk->sk_err = EPIPE;@@ -771,7 +775,7 @@ void hci_sock_dev_event(struct hci_dev *hdev, int event) hci_dev_put(hdev); } - release_sock(sk); + bh_unlock_sock(sk); } read_unlock(&hci_sk_list.lock); }The sad thing is that it seems will cost CPU resource to do meaningless wait... What do you think? Can this sock_owned_by_user() function do any help?
I don't think it helps. One of problems we are seeing (and my patch will fix) is a race window that this sk_for_each() loop needs to wait using lock_sock() because "hci_pi(sk)->hdev = hdev;" is called by hci_sock_bind() under lock_sock(). Doing hci_pi(sk)->hdev == hdev comparison without lock_sock() will lead to failing to "/* Detach sockets from device */".