oss-sec mailing list archives

Linux: Race can lead to UAF in net/bluetooth/sco.c: sco_sock_connect()


From: Solar Designer <solar () openwall com>
Date: Fri, 29 Nov 2024 05:40:32 +0100

Hi,

Upon expiration of the maximum of 14 days embargo, I am forwarding a
vulnerability report (and a couple of replies) that was erroneously
sent to the linux-distros list and then was not fully handled.  We
require information actionable for the distros within the maximum of 14
days, which generally means that the upstream should be contacted first
and should have a fix ready for the distros to include (or at least
should expect that by the proposed public disclosure date).  The
specific wording we use is:

"For Linux kernel issues, you must notify the kernel security team first,
wait for the fix, and only then notify linux-distros or oss-security
(depending on whether the information is still private or already
public, as well as on issue severity)."

While we assume good faith even if the report is misaddressed (which we
understand does happen as instructions are naturally more complicated
than we'd have liked), unfortunately this time the reporter also did not
reply to any of linux-distros' members questions, most notably "have you
contacted either security () kernel org or the bluetooth maintainers about
this issue?"  Ideally, someone from linux-distros should have taken over
and handled this fully - including asking s@k.o and the maintainers
directly - but unfortunately this also did not happen this time.

As you can see from the messages below, the issue may be the same as
CVE-2024-27398 fixed by commit 483bc08181827fc475643272ffb69c533007e546
("Bluetooth: Fix use-after-free bugs caused by sco_sock_timeout").  The
report claims that the "race condition bug has not been solved yet" by
this commit, but then the only testing appears to have been on a kernel
pre-dating this commit.

I'm also attaching here some of the files from the reporter's referenced
GitHub repo.  The main claimed PoC is a 9 MB file Linux-6.8.0-PoC.webm,
not attached here, but I do attach the proposed patch, test.c "test case
after patch" (as the commit message said), and most-relevant files from
inside PoC.zip.  I preserved the filenames, but edited the Makefile and
#include directives to avoid dependency on otherwise-unused files.  Both
programs (test.c and poc.c) build for me on Rocky Linux 9.5 with
bluez-libs-devel and fuse-devel installed.  I did not try running them.

On a related note, my searching Linux kernel mailing lists for related
keywords finds other issues also in Bluetooth and even specifically in
SCO triggered by syzbot and with recent proposed patches:

2024-11-25 13:16 [syzbot] [bluetooth?] KASAN: slab-use-after-free Read in sco_sock_connect syzbot
2024-11-25 23:58 ` [PATCH] Bluetooth: SCO: remove the redundant sco_conn_put Edward Adam Davis

Alexander

From: tianshu qiu <jimuchutianshu97 () gmail com>
To: linux-distros
Subject: [vs-plain] Race condition vulnerability that can lead to UAF in net/bluetooth/sco.c:sco_sock_connect
Date: Thu, 14 Nov 2024 18:35:24 +0800

On Thu, Nov 14, 2024 at 06:35:24PM +0800, tianshu qiu wrote:
The bug was introduced on Apr 11, 2023:
https://github.com/torvalds/linux/commit/9a8ec9e8ebb5a7c0cfbce2d6b4a6b67b2b78e8f3

=*=*=*=*=*=*=*=*==*=*=*=*=*=*=*=*==*=*=*=*=*=*=*=*= BUG DETAILS
=*=*=*=*=*=*=*=*==*=*=*=*=*=*=*=*==*=*=*=*=*=*=*=*==*=*=*=*=*=*=*=*=

I found the bug when looking for unlocked access to ???struct sock???
objects in the ???net??? directory. I think that "struct sock" is shared
among multiple threads.
Access to struct sock object, especially reading and writing sk
->sk_state, should call lock_sock(sk) in advance to lock, and call
release_sock(sk) to
unlock after the last access to ???struct sock??? object, so as to prevent
race between threads.

=*=*=*=*=*=*=*=*==*=*=*=*=*=*=*=*==*=*=*=*=*=*=*=*==*=*=*=*=*=*=*=*==*=*=*=*=*=*=*=*==*=*=*=*=*=*=*=*==*=*=*=*=*=*=*=*==*=*=*=*=*=*=*=*=

static int sco_sock_connect(struct socket *sock, struct sockaddr
*addr, int alen, int flags)
{
        struct sockaddr_sco *sa = (struct sockaddr_sco *) addr;
        struct sock *sk = sock->sk;
        int err;

        BT_DBG("sk %p", sk);

        if (alen < sizeof(struct sockaddr_sco) ||
        addr->sa_family != AF_BLUETOOTH)
        return -EINVAL;

        if (sk->sk_state != BT_OPEN && sk->sk_state != BT_BOUND)
                return -EBADFD;

        if (sk->sk_type != SOCK_SEQPACKET)
                err = -EINVAL;

        lock_sock(sk);
              // first lock-release pair
        /* Set destination address and psm */
        bacpy(&sco_pi(sk)->dst, &sa->sco_bdaddr);
        release_sock(sk);
           // first lock-release pair

        err = sco_connect(sk);
        if (err)
                return err;

        lock_sock(sk);
                 // second lock-release pair

        err = bt_sock_wait_state(sk, BT_CONNECTED,
        sock_sndtimeo(sk, flags & O_NONBLOCK));

        release_sock(sk);
             // second lock-release pair
        return err;
}



static int sco_connect(struct sock *sk)
{
        struct sco_conn *conn;
        struct hci_conn *hcon;
        struct hci_dev  *hdev;

        ??????

        hdev = hci_get_route(&sco_pi(sk)->dst, &sco_pi(sk)->src, BDADDR_BREDR);
        if (!hdev)
                return -EHOSTUNREACH;

        hci_dev_lock(hdev);

        ??????

        hcon = hci_connect_sco(hdev, type, &sco_pi(sk)->dst,
        sco_pi(sk)->setting, &sco_pi(sk)->codec);

        ??????

        lock_sock(sk);
                 // third lock-release pair

        err = sco_chan_add(conn, sk, NULL);
        if (err) {
                release_sock(sk);
                goto unlock;
        }

        /* Update source addr of the socket */
        bacpy(&sco_pi(sk)->src, &hcon->src);

        if (hcon->state == BT_CONNECTED) {
                sco_sock_clear_timer(sk);
                sk->sk_state = BT_CONNECTED;
        } else {
                sk->sk_state = BT_CONNECT;
                sco_sock_set_timer(sk, sk->sk_sndtimeo);
        }

        release_sock(sk);
             // third lock-release pair

        ......

}

=*=*=*=*=*=*=*=*==*=*=*=*=*=*=*=*==*=*=*=*=*=*=*=*==*=*=*=*=*=*=*=*==*=*=*=*=*=*=*=*==*=*=*=*=*=*=*=*==*=*=*=*=*=*=*=*==*=*=*=*=*=*=*=*=

To avoid possible circular locking, the commit that introduced the bug
splits the "lock-release" pair which protects the whole
sco_sock_connect to three parts.

The "if" branch for determining sk ->sk_state in sco_sock_connect is
exposed outside the lock_sock(sk) protection, which can lead to race
condition if two threads
execute ???connect??? system calls simultaneously.
This will lead to dangling ???struct sco_conn??? object in the function
sco_chan_add, the calling procedure is:
sco_sock_connect -> sco_connect -> sco_chan_add -> __sco_chan_add.

The timer associated to this dangling ???struct sco_conn??? object is
still work, even if the "struct sock" object was freed by the system
call "close", which will cause
UAF when timeout is reached.

Although the following two commits attempt to solve the UAF issue in
sco_sock_timeout, race condition bug has not been solved yet:

https://github.com/torvalds/linux/commit/1bf4470a3939c678fb822073e9ea77a0560bc6bb
https://github.com/torvalds/linux/commit/483bc08181827fc475643272ffb69c533007e546

This is a serious vulnerability that can cause local privilege
escalation. I hope this vulnerability can be patched and assigned a
CVE number.

=*=*=*=*=*=*=*=*==*=*=*=*=*=*=*=*==*=*=*=*=*=*=*=*==*=*=*=*=*=*=*=*=
DMESG LOG =*=*=*=*=*=*=*=*==*=*=*=*=*=*=*=*==*=*=*=*=*=*=*=*==*=*=*=*=*=*=*=*=


[ 1084.906919] BUG: KASAN: slab-use-after-free in sco_conn_del+0xa6/0x220
[ 1084.906940] Write of size 4 at addr ffff888122c06880 by task
kworker/u265:0/162

[ 1084.906955] CPU: 0 PID: 162 Comm: kworker/u265:0 Not tainted 6.8.0 #4
[ 1084.906966] Hardware name: VMware, Inc. VMware Virtual
Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020
[ 1084.906974] Workqueue: hci0 hci_rx_work
[ 1084.906991] Call Trace:
[ 1084.906996]  <TASK>
[ 1084.907004]  dump_stack_lvl+0x48/0x70
[ 1084.907018]  print_report+0xd2/0x670
[ 1084.907028]  ? __pfx__raw_spin_lock_irqsave+0x10/0x10
[ 1084.907039]  ? kasan_complete_mode_report_info+0x8a/0x230
[ 1084.907052]  kasan_report+0xd7/0x120
[ 1084.907060]  ? sco_conn_del+0xa6/0x220
[ 1084.907070]  ? sco_conn_del+0xa6/0x220
[ 1084.907082]  kasan_check_range+0x11c/0x200
[ 1084.907092]  __kasan_check_write+0x14/0x30
[ 1084.907103]  sco_conn_del+0xa6/0x220
[ 1084.907114]  sco_connect_cfm+0x1d4/0xac0
[ 1084.907125]  ? __pfx_sco_connect_cfm+0x10/0x10
[ 1084.907135]  ? __pfx_mutex_lock+0x10/0x10
[ 1084.907147]  hci_sco_setup+0x397/0x570
[ 1084.907157]  ? __pfx_hci_sco_setup+0x10/0x10
[ 1084.907165]  ? __pfx_mutex_lock+0x10/0x10
[ 1084.907176]  hci_conn_complete_evt+0x957/0x1150
[ 1084.907186]  ? kasan_save_track+0x14/0x40
[ 1084.907196]  ? __pfx_hci_conn_complete_evt+0x10/0x10
[ 1084.907205]  ? __kasan_check_write+0x14/0x30
[ 1084.907216]  ? mutex_unlock+0x81/0xe0
[ 1084.907224]  ? __pfx_mutex_unlock+0x10/0x10
[ 1084.907235]  hci_event_packet+0x818/0x1080
[ 1084.907246]  ? __pfx_hci_conn_complete_evt+0x10/0x10
[ 1084.907256]  ? __pfx_hci_event_packet+0x10/0x10
[ 1084.907266]  ? __pfx__raw_spin_lock_irqsave+0x10/0x10
[ 1084.907275]  ? __pfx_hci_cmd_sync_complete+0x10/0x10
[ 1084.907286]  ? __kasan_check_read+0x11/0x20
[ 1084.907297]  hci_rx_work+0x312/0xd60
[ 1084.907308]  ? __pfx__raw_spin_lock_irq+0x10/0x10
[ 1084.907318]  process_one_work+0x577/0xd30
[ 1084.907371]  ? _raw_spin_lock_irq+0x8b/0x100
[ 1084.907384]  worker_thread+0x879/0x15a0
[ 1084.907392]  ? __pfx__raw_spin_lock_irqsave+0x10/0x10
[ 1084.907403]  ? __pfx_worker_thread+0x10/0x10
[ 1084.907411]  kthread+0x2b7/0x390
[ 1084.907421]  ? __pfx_kthread+0x10/0x10
[ 1084.907431]  ret_from_fork+0x44/0x90
[ 1084.907442]  ? __pfx_kthread+0x10/0x10
[ 1084.907451]  ret_from_fork_asm+0x1b/0x30
[ 1084.907497]  </TASK>

[ 1084.907506] Allocated by task 3974:
[ 1084.907513]  kasan_save_stack+0x39/0x70
[ 1084.907522]  kasan_save_track+0x14/0x40
[ 1084.907527]  kasan_save_alloc_info+0x37/0x60
[ 1084.907537]  __kasan_kmalloc+0xc3/0xd0
[ 1084.907543]  __kmalloc+0x21f/0x530
[ 1084.907551]  sk_prot_alloc+0x16d/0x220
[ 1084.907560]  sk_alloc+0x35/0x750
[ 1084.907568]  bt_sock_alloc+0x2f/0x360
[ 1084.907576]  sco_sock_create+0xc6/0x390
[ 1084.907617]  bt_sock_create+0x152/0x320
[ 1084.907629]  __sock_create+0x212/0x500
[ 1084.907636]  __sys_socket+0x139/0x210
[ 1084.907670]  __x64_sys_socket+0x72/0xc0
[ 1084.907677]  do_syscall_64+0x82/0x180
[ 1084.907684]  entry_SYSCALL_64_after_hwframe+0x6e/0x76

[ 1084.907750] Freed by task 3974:
[ 1084.907755]  kasan_save_stack+0x39/0x70
[ 1084.907760]  kasan_save_track+0x14/0x40
[ 1084.907764]  kasan_save_free_info+0x3b/0x60
[ 1084.907769]  poison_slab_object+0x10a/0x180
[ 1084.907773]  __kasan_slab_free+0x33/0x60
[ 1084.907777]  kfree+0xda/0x2f0
[ 1084.907782]  __sk_destruct+0x44e/0x640
[ 1084.907787]  sk_destruct+0xaa/0xd0
[ 1084.907792]  __sk_free+0xa5/0x300
[ 1084.907797]  sk_free+0x50/0x80
[ 1084.907802]  sco_sock_kill+0x12e/0x160
[ 1084.907808]  sco_sock_release+0x134/0x290
[ 1084.907813]  __sock_release+0xac/0x270
[ 1084.907817]  sock_close+0x15/0x30
[ 1084.907821]  __fput+0x205/0xa90
[ 1084.907825]  __fput_sync+0x3a/0x50
[ 1084.907829]  __x64_sys_close+0x7e/0xe0
[ 1084.907835]  do_syscall_64+0x82/0x180
[ 1084.907839]  entry_SYSCALL_64_after_hwframe+0x6e/0x76

[ 1084.907847] The buggy address belongs to the object at ffff888122c06800
         which belongs to the cache kmalloc-rnd-04-1k of size 1024
[ 1084.907852] The buggy address is located 128 bytes inside of
         freed 1024-byte region [ffff888122c06800, ffff888122c06c00)

[ 1084.907861] The buggy address belongs to the physical page:
[ 1084.907865] page:00000000dd0be509 refcount:1 mapcount:0
mapping:0000000000000000 index:0x0 pfn:0x122c00
[ 1084.907871] head:00000000dd0be509 order:3 entire_mapcount:0
nr_pages_mapped:0 pincount:0
[ 1084.907876] flags:
0x17ffffc0000840(slab|head|node=0|zone=2|lastcpupid=0x1fffff)
[ 1084.907882] page_type: 0xffffffff()
[ 1084.907887] raw: 0017ffffc0000840 ffff88810004f040 dead000000000122
0000000000000000
[ 1084.907892] raw: 0000000000000000 0000000080100010 00000001ffffffff
0000000000000000
[ 1084.907895] page dumped because: kasan: bad access detected

[ 1084.907900] Memory state around the buggy address:
[ 1084.907904]  ffff888122c06780: fc fc fc fc fc fc fc fc fc fc fc fc
fc fc fc fc
[ 1084.907908]  ffff888122c06800: fa fb fb fb fb fb fb fb fb fb fb fb
fb fb fb fb
[ 1084.907913] >ffff888122c06880: fb fb fb fb fb fb fb fb fb fb fb fb
fb fb fb fb
[ 1084.907916]                    ^
[ 1084.907920]  ffff888122c06900: fb fb fb fb fb fb fb fb fb fb fb fb
fb fb fb fb
[ 1084.907923]  ffff888122c06980: fb fb fb fb fb fb fb fb fb fb fb fb
fb fb fb fb
[ 1084.907927] ==================================================================
[ 1084.908048] Disabling lock debugging due to kernel taint
[ 1084.908054] ------------[ cut here ]------------
[ 1084.908057] refcount_t: addition on 0; use-after-free.
[ 1084.908141] WARNING: CPU: 0 PID: 162 at lib/refcount.c:25
refcount_warn_saturate+0x171/0x1a0
[ 1084.908174] Modules linked in: isofs snd_seq_dummy snd_hrtimer qrtr
intel_rapl_msr intel_rapl_common intel_uncore_frequency_common
intel_pmc_core intel_vsec pmt_telemetry pmt_class crct10dif_pclmul
polyval_clmulni snd_ens1371 polyval_generic snd_ac97_codec
ghash_clmulni_intel gameport sha256_ssse3 ac97_bus vmw_balloon
sha1_ssse3 snd_pcm aesni_intel uvcvideo crypto_simd snd_seq_midi
cryptd rapl snd_seq_midi_event videobuf2_vmalloc uvc snd_rawmidi
videobuf2_memops videobuf2_v4l2 snd_seq snd_seq_device videodev
snd_timer videobuf2_common snd mc btusb btmtk soundcore i2c_piix4
input_leds joydev mac_hid serio_raw vsock_loopback binfmt_misc
vmw_vsock_virtio_transport_common vmw_vsock_vmci_transport vsock
vmw_vmci sch_fq_codel ramoops reed_solomon vmwgfx drm_ttm_helper ttm
msr parport_pc ppdev lp parport efi_pstore nfnetlink dmi_sysfs
ip_tables x_tables autofs4 hid_generic crc32_pclmul usbhid psmouse
mptspi mptscsih e1000 ahci mptbase libahci scsi_transport_spi
pata_acpi floppy
[ 1084.908607] CPU: 0 PID: 162 Comm: kworker/u265:0 Tainted: G    B
          6.8.0 #4
[ 1084.908614] Hardware name: VMware, Inc. VMware Virtual
Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020
[ 1084.908618] Workqueue: hci0 hci_rx_work
[ 1084.908627] RIP: 0010:refcount_warn_saturate+0x171/0x1a0
[ 1084.908634] Code: 1d 81 1a eb 03 80 fb 01 0f 87 13 6f df 01 83 e3
01 0f 85 4f ff ff ff 48 c7 c7 40 1c aa 84 c6 05 61 1a eb 03 01 e8 ef
de c3 fe <0f> 0b e9 35 ff ff ff 48 89 df e8 f0 99 59 ff e9 bc fe ff ff
48 c7
[ 1084.908639] RSP: 0018:ffff888134717940 EFLAGS: 00010246
[ 1084.908644] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
[ 1084.908648] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
[ 1084.908651] RBP: ffff888134717950 R08: 0000000000000000 R09: 0000000000000000
[ 1084.908654] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000002
[ 1084.908657] R13: ffff888104589000 R14: ffff888104589780 R15: ffff88810033dc08
[ 1084.908661] FS:  0000000000000000(0000) GS:ffff8881f3200000(0000)
knlGS:0000000000000000
[ 1084.908665] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 1084.908669] CR2: 000062bcbcecc5a0 CR3: 000000011de7a002 CR4: 00000000003706f0
[ 1084.908673] Call Trace:
[ 1084.908692]  <TASK>
[ 1084.908695]  ? show_regs+0x6d/0x80
[ 1084.908702]  ? __warn+0xcd/0x270
[ 1084.908706]  ? refcount_warn_saturate+0x171/0x1a0
[ 1084.908710]  ? report_bug+0x288/0x310
[ 1084.908715]  ? vprintk_default+0x1d/0x30
[ 1084.908720]  ? handle_bug+0x9f/0xd0
[ 1084.908724]  ? exc_invalid_op+0x18/0x50
[ 1084.908728]  ? asm_exc_invalid_op+0x1b/0x20
[ 1084.908736]  ? refcount_warn_saturate+0x171/0x1a0
[ 1084.908741]  sco_conn_del+0x1ef/0x220
[ 1084.908746]  sco_connect_cfm+0x1d4/0xac0
[ 1084.908751]  ? __pfx_sco_connect_cfm+0x10/0x10
[ 1084.908756]  ? __pfx_mutex_lock+0x10/0x10
[ 1084.908762]  hci_sco_setup+0x397/0x570
[ 1084.908766]  ? __pfx_hci_sco_setup+0x10/0x10
[ 1084.908769]  ? __pfx_mutex_lock+0x10/0x10
[ 1084.908774]  hci_conn_complete_evt+0x957/0x1150
[ 1084.908779]  ? kasan_save_track+0x14/0x40
[ 1084.908784]  ? __pfx_hci_conn_complete_evt+0x10/0x10
[ 1084.908788]  ? __kasan_check_write+0x14/0x30
[ 1084.908793]  ? mutex_unlock+0x81/0xe0
[ 1084.908797]  ? __pfx_mutex_unlock+0x10/0x10
[ 1084.908802]  hci_event_packet+0x818/0x1080
[ 1084.908807]  ? __pfx_hci_conn_complete_evt+0x10/0x10
[ 1084.908812]  ? __pfx_hci_event_packet+0x10/0x10
[ 1084.908816]  ? __pfx__raw_spin_lock_irqsave+0x10/0x10
[ 1084.908820]  ? __pfx_hci_cmd_sync_complete+0x10/0x10
[ 1084.908825]  ? __kasan_check_read+0x11/0x20
[ 1084.908831]  hci_rx_work+0x312/0xd60
[ 1084.908836]  ? __pfx__raw_spin_lock_irq+0x10/0x10
[ 1084.908841]  process_one_work+0x577/0xd30
[ 1084.908844]  ? _raw_spin_lock_irq+0x8b/0x100
[ 1084.908850]  worker_thread+0x879/0x15a0
[ 1084.908853]  ? __pfx__raw_spin_lock_irqsave+0x10/0x10
[ 1084.908859]  ? __pfx_worker_thread+0x10/0x10
[ 1084.908862]  kthread+0x2b7/0x390
[ 1084.908867]  ? __pfx_kthread+0x10/0x10
[ 1084.908871]  ret_from_fork+0x44/0x90
[ 1084.908876]  ? __pfx_kthread+0x10/0x10
[ 1084.908880]  ret_from_fork_asm+0x1b/0x30
[ 1084.908886]  </TASK>
[ 1084.908888] ---[ end trace 0000000000000000 ]---
[ 1084.908894] ------------[ cut here ]------------
[ 1084.908896] refcount_t: underflow; use-after-free.
[ 1084.908937] WARNING: CPU: 0 PID: 162 at lib/refcount.c:28
refcount_warn_saturate+0x13e/0x1a0
[ 1084.908946] Modules linked in: isofs snd_seq_dummy snd_hrtimer qrtr
intel_rapl_msr intel_rapl_common intel_uncore_frequency_common
intel_pmc_core intel_vsec pmt_telemetry pmt_class crct10dif_pclmul
polyval_clmulni snd_ens1371 polyval_generic snd_ac97_codec
ghash_clmulni_intel gameport sha256_ssse3 ac97_bus vmw_balloon
sha1_ssse3 snd_pcm aesni_intel uvcvideo crypto_simd snd_seq_midi
cryptd rapl snd_seq_midi_event videobuf2_vmalloc uvc snd_rawmidi
videobuf2_memops videobuf2_v4l2 snd_seq snd_seq_device videodev
snd_timer videobuf2_common snd mc btusb btmtk soundcore i2c_piix4
input_leds joydev mac_hid serio_raw vsock_loopback binfmt_misc
vmw_vsock_virtio_transport_common vmw_vsock_vmci_transport vsock
vmw_vmci sch_fq_codel ramoops reed_solomon vmwgfx drm_ttm_helper ttm
msr parport_pc ppdev lp parport efi_pstore nfnetlink dmi_sysfs
ip_tables x_tables autofs4 hid_generic crc32_pclmul usbhid psmouse
mptspi mptscsih e1000 ahci mptbase libahci scsi_transport_spi
pata_acpi floppy
[ 1084.909076] CPU: 0 PID: 162 Comm: kworker/u265:0 Tainted: G    B
W          6.8.0 #4
[ 1084.909081] Hardware name: VMware, Inc. VMware Virtual
Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020
[ 1084.909084] Workqueue: hci0 hci_rx_work
[ 1084.909090] RIP: 0010:refcount_warn_saturate+0x13e/0x1a0
[ 1084.909094] Code: eb 97 0f b6 1d af 1a eb 03 80 fb 01 0f 87 56 6f
df 01 83 e3 01 75 82 48 c7 c7 a0 1c aa 84 c6 05 93 1a eb 03 01 e8 22
df c3 fe <0f> 0b e9 68 ff ff ff 0f b6 1d 81 1a eb 03 80 fb 01 0f 87 13
6f df
[ 1084.909097] RSP: 0018:ffff888134717940 EFLAGS: 00010246
[ 1084.909101] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
[ 1084.909103] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
[ 1084.909106] RBP: ffff888134717950 R08: 0000000000000000 R09: 0000000000000000
[ 1084.909108] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000003
[ 1084.909110] R13: ffff888104589000 R14: ffff888104589780 R15: ffff88810033dc08
[ 1084.909113] FS:  0000000000000000(0000) GS:ffff8881f3200000(0000)
knlGS:0000000000000000
[ 1084.909116] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 1084.909119] CR2: 000062bcbcecc5a0 CR3: 000000011de7a002 CR4: 00000000003706f0
[ 1084.909122] Call Trace:
[ 1084.909124]  <TASK>
[ 1084.909127]  ? show_regs+0x6d/0x80
[ 1084.909132]  ? __warn+0xcd/0x270
[ 1084.909137]  ? refcount_warn_saturate+0x13e/0x1a0
[ 1084.909141]  ? report_bug+0x288/0x310
[ 1084.909145]  ? vprintk_default+0x1d/0x30
[ 1084.909149]  ? handle_bug+0x9f/0xd0
[ 1084.909153]  ? exc_invalid_op+0x18/0x50
[ 1084.909158]  ? asm_exc_invalid_op+0x1b/0x20
[ 1084.909164]  ? refcount_warn_saturate+0x13e/0x1a0
[ 1084.909168]  sco_conn_del+0x1dc/0x220
[ 1084.909174]  sco_connect_cfm+0x1d4/0xac0
[ 1084.909179]  ? __pfx_sco_connect_cfm+0x10/0x10
[ 1084.909184]  ? __pfx_mutex_lock+0x10/0x10
[ 1084.909189]  hci_sco_setup+0x397/0x570
[ 1084.909193]  ? __pfx_hci_sco_setup+0x10/0x10
[ 1084.909196]  ? __pfx_mutex_lock+0x10/0x10
[ 1084.909202]  hci_conn_complete_evt+0x957/0x1150
[ 1084.909206]  ? kasan_save_track+0x14/0x40
[ 1084.909211]  ? __pfx_hci_conn_complete_evt+0x10/0x10
[ 1084.909215]  ? __kasan_check_write+0x14/0x30
[ 1084.909220]  ? mutex_unlock+0x81/0xe0
[ 1084.909224]  ? __pfx_mutex_unlock+0x10/0x10
[ 1084.909228]  hci_event_packet+0x818/0x1080
[ 1084.909256]  ? __pfx_hci_conn_complete_evt+0x10/0x10
[ 1084.909261]  ? __pfx_hci_event_packet+0x10/0x10
[ 1084.909267]  ? __pfx__raw_spin_lock_irqsave+0x10/0x10
[ 1084.909272]  ? __pfx_hci_cmd_sync_complete+0x10/0x10
[ 1084.909278]  ? __kasan_check_read+0x11/0x20
[ 1084.909285]  hci_rx_work+0x312/0xd60
[ 1084.909291]  ? __pfx__raw_spin_lock_irq+0x10/0x10
[ 1084.909297]  process_one_work+0x577/0xd30
[ 1084.909301]  ? _raw_spin_lock_irq+0x8b/0x100
[ 1084.909308]  worker_thread+0x879/0x15a0
[ 1084.909312]  ? __pfx__raw_spin_lock_irqsave+0x10/0x10
[ 1084.909319]  ? __pfx_worker_thread+0x10/0x10
[ 1084.909323]  kthread+0x2b7/0x390
[ 1084.909328]  ? __pfx_kthread+0x10/0x10
[ 1084.909350]  ret_from_fork+0x44/0x90
[ 1084.909354]  ? __pfx_kthread+0x10/0x10
[ 1084.909359]  ret_from_fork_asm+0x1b/0x30
[ 1084.909364]  </TASK>
[ 1084.909366] ---[ end trace 0000000000000000 ]---

=*=*=*=*=*=*=*=*==*=*=*=*=*=*=*=*==*=*=*=*=*=*=*=*==*=*=*=*=*=*=*=*=
Environment =*=*=*=*=*=*=*=*==*=*=*=*=*=*=*=*==*=*=*=*=*=*=*=*==*=*=*=*=*=*=*=*=

linux-6.8.0
ubuntu 24.04
.config: https://github.com/qiutianshu/sco-race-condition/blob/main/config

=*=*=*=*=*=*=*=*==*=*=*=*=*=*=*=*==*=*=*=*=*=*=*=*==*=*=*=*=*=*=*=*=
Proof of Concept
=*=*=*=*=*=*=*=*==*=*=*=*=*=*=*=*==*=*=*=*=*=*=*=*==*=*=*=*=*=*=*=*=

https://github.com/qiutianshu/sco-race-condition/blob/main/Linux-6.8.0-PoC.webm

=*=*=*=*=*=*=*=*==*=*=*=*=*=*=*=*==*=*=*=*=*=*=*=*==*=*=*=*=*=*=*=*=
PATCH =*=*=*=*=*=*=*=*==*=*=*=*=*=*=*=*==*=*=*=*=*=*=*=*==*=*=*=*=*=*=*=*=

My patch removes the three "lock-release" pairs in the original
sco_sock_connect, and use a single "lock-release" pair to protect the
whole connect procedure.
Circular locking have not been observed after patching:
https://github.com/qiutianshu/sco-race-condition/blob/main/test.c

Patch:
https://github.com/qiutianshu/sco-race-condition/blob/main/diff.txt

The replies originally included some quoting of the message above, which
I excluded from the copies below.

On Thu, Nov 14, 2024 at 07:51:20PM +0100, Vegard Nossum wrote:
Hi tianshu,

Thank you for the report.

At a glance, 483bc08181827fc475643272ffb69c533007e546 looks like it was
only committed in 6.9 yet your crash/kernel messages indicate you are
testing against 6.8.0 -- are you sure this wasn't fixed already? Could
you verify with a more recent kernel?

Secondly, have you contacted either security () kernel org or the bluetooth
maintainers about this issue? The maintainers would be:

BLUETOOTH SUBSYSTEM
M:      Marcel Holtmann <marcel () holtmann org>
M:      Johan Hedberg <johan.hedberg () gmail com>
M:      Luiz Augusto von Dentz <luiz.dentz () gmail com>

Please see the kernel documentation on reporting security issues:

https://docs.kernel.org/process/security-bugs.html

For CVE assignments, you need to contact the CVE assignment team:

https://docs.kernel.org/process/cve.html

However, be aware that CVE-2024-27398 was already assigned to the issue
fixed by commit 483bc08181827fc475643272ffb69c533007e546 ("Bluetooth:
Fix use-after-free bugs caused by sco_sock_timeout") -- which, if it's
the same issue, would also be the same CVE.

I admit I haven't looked very closely at the code yet, I will try to
take a better look tomorrow. (Anybody else on the list is obviously
welcome to look as well.)

Finally, I will point out that we usually require reporters to set an
embargo end-date according to the linux-distros list policy (usually 7
days, no more than 14 days), after which your report must also be made
public by posting it to oss-security; see:

https://oss-security.openwall.org/wiki/mailing-lists/distros#list-policy-and-instructions-for-reporters

Thanks,

Vegard

On Mon, Nov 18, 2024 at 09:33:27PM +0100, Salvatore Bonaccorso wrote:
Hi,

Question back on your report: have you reached out first to the kernel
security team?

Cf. https://oss-security.openwall.org/wiki/mailing-lists/distros#list-policy-and-instructions-for-reporters

| Please consider notifying upstream projects/developers of the affected
| software, other affected distro vendors, and/or affected Open Source
| projects before notifying one of these mailing lists in order to
| readily have fixes for the distributions to apply and to ensure that
| these other parties are OK with the maximum embargo period that would
| apply (if not, you may delay your notification to the mailing list).
| For Linux kernel issues, you must notify the kernel security team
| first, wait for the fix, and only then notify linux-distros or
| oss-security (depending on whether the information is still private or
| already public, as well as on issue severity).

Regards,
Salvatore

Attachment: diff.txt
Description:

Attachment: test.c
Description:

Attachment: Makefile
Description:

Attachment: poc.c
Description:

Attachment: fake_fuse.c
Description:

Attachment: fake_fuse.h
Description:


Current thread: