From: Takashi Iwai <tiwai@suse.de>
To: linux-bluetooth@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Subject: CVE-2021-3640 and the unlimited block of lock_sock()
Date: Thu, 19 Aug 2021 17:46:39 +0200 [thread overview]
Message-ID: <s5hv9418mjk.wl-tiwai@suse.de> (raw)
Hi,
it seems that the recent fixes in bluetooth tree address most of
issues in CVE-2021-3640 ("Use-After-Free vulnerability in function
sco_sock_sendmsg()"). But there is still a problem left: although we
cover the race with lock_sock() now, the lock may be blocked endlessly
(as the task takes over with userfaultd), which result in the trigger
of watchdog like:
-- 8< --
[ 23.226767][ T7] Bluetooth: hci0: command 0x0419 tx timeout
[ 284.985881][ T1529] INFO: task poc:7603 blocked for more than 143 seconds.
[ 284.989134][ T1529] Not tainted 5.13.0-rc4+ #48
[ 284.990098][ T1529] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 284.991705][ T1529] task:poc state:D stack:13784 pid: 7603 ppid: 7593 flags:0x00000000
[ 284.993414][ T1529] Call Trace:
[ 284.994025][ T1529] __schedule+0x32e/0xb90
[ 284.994842][ T1529] ? __local_bh_enable_ip+0x72/0xe0
[ 284.995987][ T1529] schedule+0x38/0xe0
[ 284.996723][ T1529] __lock_sock+0xa1/0x130
[ 284.997434][ T1529] ? finish_wait+0x80/0x80
[ 284.998150][ T1529] lock_sock_nested+0x9f/0xb0
[ 284.998914][ T1529] sco_conn_del+0xb1/0x1a0
[ 284.999619][ T1529] ? sco_conn_del+0x1a0/0x1a0
[ 285.000361][ T1529] sco_disconn_cfm+0x3a/0x60
[ 285.001116][ T1529] hci_conn_hash_flush+0x95/0x130
[ 285.001921][ T1529] hci_dev_do_close+0x298/0x680
[ 285.002687][ T1529] ? up_write+0x12/0x130
[ 285.003367][ T1529] ? vhci_close_dev+0x20/0x20
[ 285.004107][ T1529] hci_unregister_dev+0x9f/0x240
[ 285.004886][ T1529] vhci_release+0x35/0x70
[ 285.005602][ T1529] __fput+0xdf/0x360
[ 285.006225][ T1529] task_work_run+0x86/0xd0
[ 285.006927][ T1529] exit_to_user_mode_prepare+0x267/0x270
[ 285.007824][ T1529] syscall_exit_to_user_mode+0x19/0x60
[ 285.008694][ T1529] do_syscall_64+0x42/0xa0
[ 285.009393][ T1529] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 285.010321][ T1529] RIP: 0033:0x4065c7
-- 8< --
Is there any plan to address this?
As a quick hack, I confirmed a workaround like below:
-- 8< --
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -2628,7 +2628,7 @@ void __lock_sock(struct sock *sk)
prepare_to_wait_exclusive(&sk->sk_lock.wq, &wait,
TASK_UNINTERRUPTIBLE);
spin_unlock_bh(&sk->sk_lock.slock);
- schedule();
+ schedule_timeout(msecs_to_jiffies(10 * 1000));
spin_lock_bh(&sk->sk_lock.slock);
if (!sock_owned_by_user(sk))
break;
-- 8< --
.... but I'm not sure whether it's the right way to go.
thanks,
Takashi
next reply other threads:[~2021-08-19 15:46 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-19 15:46 Takashi Iwai [this message]
2021-08-19 16:14 ` CVE-2021-3640 and the unlimited block of lock_sock() bluez.test.bot
2021-08-26 10:27 ` Takashi Iwai
2021-08-27 1:28 ` Luiz Augusto von Dentz
2021-08-28 16:06 ` Takashi Iwai
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=s5hv9418mjk.wl-tiwai@suse.de \
--to=tiwai@suse.de \
--cc=linux-bluetooth@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/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.