| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <tencent_7C305172EDB8B9ECD59983C9E4B44FF1BA09@qq.com>
Date: Wed, 5 Mar 2025 08:35:17 -0500
From: "ffhgfv" <744439878@...com>
To: "marcel" <marcel@...tmann.org>, "johan.hedberg" <johan.hedberg@...il.com>, "luiz.dentz" <luiz.dentz@...il.com>, "linux-bluetooth" <linux-bluetooth@...r.kernel.org>, "linux-kernel" <linux-kernel@...r.kernel.org>
Subject: kernel bug found in bluetooth and suggestions for fixing it
Hello, I found a bug titled “ KASAN: slab-out-of-bounds Write in sco_conn_put ”with modified syzkaller in the lasted upstream related to bluetooth subsystem.
If you fix this issue, please add the following tag to the commit: Reported-by: Jianzhou Zhao<xnxc22xnxc22@...com> xingwei lee <xrivendell7@...il.com> Zhizhuo Tang <strforexctzzchange@...mail.com>
------------[ cut here ]------------
TITLE: BUG: KASAN: slab-out-of-bounds Write in sco_conn_put
==================================================================
=================================================================
BUG: KASAN: slab-out-of-bounds in sco_conn_free net/bluetooth/sco.c:87 [inline]
BUG: KASAN: slab-out-of-bounds in kref_put include/linux/kref.h:65 [inline]
BUG: KASAN: slab-out-of-bounds in sco_conn_put+0x479/0x4d0 net/bluetooth/sco.c:107
Write of size 8 at addr ffff888028b075a0 by task syz-executor/12481
CPU: 1 UID: 0 PID: 12481 Comm: syz-executor Not tainted 6.14.0-rc5-dirty #2
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
Call Trace:
<task>
__dump_stack lib/dump_stack.c:94 [inline]
dump_stack_lvl+0x116/0x1b0 lib/dump_stack.c:120
print_address_description mm/kasan/report.c:408 [inline]
print_report+0xc1/0x630 mm/kasan/report.c:521
kasan_report+0xbd/0xf0 mm/kasan/report.c:634
sco_conn_free net/bluetooth/sco.c:87 [inline]
kref_put include/linux/kref.h:65 [inline]
sco_conn_put+0x479/0x4d0 net/bluetooth/sco.c:107
sco_conn_del+0x25f/0x2f0 net/bluetooth/sco.c:263
hci_disconn_cfm include/net/bluetooth/hci_core.h:2069 [inline]
hci_conn_hash_flush+0x44b/0x780 net/bluetooth/hci_conn.c:2698
hci_dev_close_sync+0x5b0/0x11a0 net/bluetooth/hci_sync.c:5197
hci_dev_do_close+0x31/0xa0 net/bluetooth/hci_core.c:482
hci_unregister_dev+0x213/0x630 net/bluetooth/hci_core.c:2677
vhci_release+0x7a/0xf0 drivers/bluetooth/hci_vhci.c:664
__fput+0x3ff/0xb50 fs/file_table.c:464
task_work_run+0x169/0x260 kernel/task_work.c:227
exit_task_work include/linux/task_work.h:40 [inline]
do_exit+0xade/0x2d00 kernel/exit.c:938
do_group_exit+0xd3/0x2a0 kernel/exit.c:1087
get_signal+0x2278/0x2540 kernel/signal.c:3036
arch_do_signal_or_restart+0x81/0x7d0 arch/x86/kernel/signal.c:337
exit_to_user_mode_loop kernel/entry/common.c:111 [inline]
exit_to_user_mode_prepare include/linux/entry-common.h:329 [inline]
__syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline]
syscall_exit_to_user_mode+0x150/0x2a0 kernel/entry/common.c:218
do_syscall_64+0xd8/0x250 arch/x86/entry/common.c:89
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7fd514dabbb6
Code: Unable to access opcode bytes at 0x7fd514dabb8c.
RSP: 002b:00007fff2dbb8ac0 EFLAGS: 00000293 ORIG_RAX: 000000000000002c
RAX: 0000000000000028 RBX: 00007fd515af4620 RCX: 00007fd514dabbb6
RDX: 0000000000000028 RSI: 00007fd515af4670 RDI: 0000000000000003
RBP: 0000000000000001 R08: 00007fff2dbb8b1c R09: 000000000000000c
R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000
R13: 00007fd515af4670 R14: 0000000000000003 R15: 0000000000000000
</task>
Allocated by task 13326:
kasan_save_stack+0x24/0x50 mm/kasan/common.c:47
kasan_save_track+0x14/0x30 mm/kasan/common.c:68
poison_kmalloc_redzone mm/kasan/common.c:377 [inline]
__kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:394
kmalloc_noprof include/linux/slab.h:901 [inline]
kzalloc_noprof include/linux/slab.h:1037 [inline]
rxrpc_alloc_connection+0x91/0x780 net/rxrpc/conn_object.c:62
rxrpc_prealloc_service_connection+0x28/0x3a0 net/rxrpc/conn_service.c:123
rxrpc_service_prealloc_one+0x2c5/0xf20 net/rxrpc/call_accept.c:87
rxrpc_kernel_charge_accept+0xd8/0x120 net/rxrpc/call_accept.c:475
afs_charge_preallocation+0xbe/0x310 fs/afs/rxrpc.c:739
afs_open_socket+0x290/0x360 fs/afs/rxrpc.c:95
afs_net_init+0x966/0xc60 fs/afs/main.c:123
ops_init+0x1df/0x5f0 net/core/net_namespace.c:138
setup_net+0x21f/0x870 net/core/net_namespace.c:362
copy_net_ns+0x2aa/0x600 net/core/net_namespace.c:516
create_new_namespaces+0x3f6/0xaf0 kernel/nsproxy.c:110
unshare_nsproxy_namespaces+0xc0/0x200 kernel/nsproxy.c:228
ksys_unshare+0x462/0xa00 kernel/fork.c:3342
__do_sys_unshare kernel/fork.c:3413 [inline]
__se_sys_unshare kernel/fork.c:3411 [inline]
__x64_sys_unshare+0x31/0x40 kernel/fork.c:3411
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xcb/0x250 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
The buggy address belongs to the object at ffff888028b07000
which belongs to the cache kmalloc-2k of size 2048
The buggy address is located 304 bytes to the right of
allocated 1136-byte region [ffff888028b07000, ffff888028b07470)
The buggy address belongs to the physical page:
page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x28b00
head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0
flags: 0xfff00000000040(head|node=0|zone=1|lastcpupid=0x7ff)
page_type: f5(slab)
raw: 00fff00000000040 ffff88801b042000 dead000000000100 dead000000000122
raw: 0000000000000000 0000000000080008 00000000f5000000 0000000000000000
head: 00fff00000000040 ffff88801b042000 dead000000000100 dead000000000122
head: 0000000000000000 0000000000080008 00000000f5000000 0000000000000000
head: 00fff00000000003 ffffea0000a2c001 ffffffffffffffff 0000000000000000
head: 0000000000000008 0000000000000000 00000000ffffffff 0000000000000000
page dumped because: kasan: bad access detected
page_owner tracks the page as allocated
page last allocated via order 3, migratetype Unmovable, gfp_mask 0xd20c0(__GFP_IO|__GFP_FS|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC), pid 9488, tgid 9488 (syz-executor), ts 260505925503, free_ts 198428693595
set_page_owner include/linux/page_owner.h:32 [inline]
post_alloc_hook+0x193/0x1c0 mm/page_alloc.c:1551
prep_new_page mm/page_alloc.c:1559 [inline]
get_page_from_freelist+0xe4e/0x2b20 mm/page_alloc.c:3477
__alloc_frozen_pages_noprof+0x219/0x21f0 mm/page_alloc.c:4739
alloc_pages_mpol+0x1f2/0x540 mm/mempolicy.c:2270
alloc_slab_page mm/slub.c:2423 [inline]
allocate_slab mm/slub.c:2587 [inline]
new_slab+0x248/0x350 mm/slub.c:2640
___slab_alloc+0xbb2/0x1810 mm/slub.c:3826
__slab_alloc.constprop.0+0x56/0xb0 mm/slub.c:3916
__slab_alloc_node mm/slub.c:3991 [inline]
slab_alloc_node mm/slub.c:4152 [inline]
__kmalloc_cache_noprof+0x280/0x410 mm/slub.c:4320
kmalloc_noprof include/linux/slab.h:901 [inline]
rtnl_newlink+0xd0/0x1cf0 net/core/rtnetlink.c:3922
rtnetlink_rcv_msg+0x9e3/0xfb0 net/core/rtnetlink.c:6912
netlink_rcv_skb+0x165/0x440 net/netlink/af_netlink.c:2533
netlink_unicast_kernel net/netlink/af_netlink.c:1312 [inline]
netlink_unicast+0x544/0x800 net/netlink/af_netlink.c:1338
netlink_sendmsg+0x8a5/0xd80 net/netlink/af_netlink.c:1882
sock_sendmsg_nosec net/socket.c:718 [inline]
__sock_sendmsg net/socket.c:733 [inline]
__sys_sendto+0x4fc/0x570 net/socket.c:2187
__do_sys_sendto net/socket.c:2194 [inline]
__se_sys_sendto net/socket.c:2190 [inline]
__x64_sys_sendto+0xe0/0x1c0 net/socket.c:2190
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xcb/0x250 arch/x86/entry/common.c:83
page last free pid 9305 tgid 9305 stack trace:
reset_page_owner include/linux/page_owner.h:25 [inline]
free_pages_prepare mm/page_alloc.c:1127 [inline]
free_frozen_pages+0x718/0xfd0 mm/page_alloc.c:2660
__put_partials+0x154/0x170 mm/slub.c:3153
qlink_free mm/kasan/quarantine.c:163 [inline]
qlist_free_all+0x50/0x120 mm/kasan/quarantine.c:179
kasan_quarantine_reduce+0x195/0x1e0 mm/kasan/quarantine.c:286
__kasan_slab_alloc+0x67/0x90 mm/kasan/common.c:329
kasan_slab_alloc include/linux/kasan.h:250 [inline]
slab_post_alloc_hook mm/slub.c:4115 [inline]
slab_alloc_node mm/slub.c:4164 [inline]
__do_kmalloc_node mm/slub.c:4293 [inline]
__kmalloc_noprof+0x1c3/0x530 mm/slub.c:4306
kmalloc_noprof include/linux/slab.h:905 [inline]
tomoyo_realpath_from_path+0xc3/0x600 security/tomoyo/realpath.c:251
tomoyo_get_realpath security/tomoyo/file.c:151 [inline]
tomoyo_path_perm+0x236/0x430 security/tomoyo/file.c:822
security_inode_getattr+0x122/0x2b0 security/security.c:2377
vfs_getattr fs/stat.c:243 [inline]
vfs_fstat+0x50/0xc0 fs/stat.c:265
__do_sys_newfstat+0x84/0x100 fs/stat.c:542
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xcb/0x250 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Memory state around the buggy address:
ffff888028b07480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff888028b07500: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>ffff888028b07580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
^
ffff888028b07600: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff888028b07680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
==================================================================
==================================================================
I use the same kernel as syzbot instance upstream: 7eb172143d5508b4da468ed59ee857c6e5e01da6
kernel config: https://syzkaller.appspot.com/text?tag=KernelConfig&amp;amp;x=da4b04ae798b7ef6
compiler: gcc version 11.4.0
===============================================================================
Unfortunately, the modified syzkaller does not generate an effective repeat program.
The following is my analysis of the bug and repair suggestions, hoping to help with the repair of the bug:
Root cause:
UAF (Use-After-Free) : When the socket pointed to conn->sk has been released, but the sco_conn structure still retains its pointer, the overreach is triggered when the sco_pi(conn->sk) is accessed.
Lifecycle management flaw: Bidirectional references of Socket and SCO connections do not synchronize the release order correctly, resulting in access to freed socket memory.
### Repair suggestions
1. Actively disconnect the connection reference when the Socket is released.Modify the Socket release logic to ensure that the associated conn->sk pointer is cleared during destruction to avoid subsequent access.
// net/bluetooth/sco.c
static void sco_sock_destruct(struct sock *sk)
{
++ struct sco_conn *conn = sco_pi(sk)->conn;
-- BT_DBG("sk %p", sk);
++ BT_DBG("sk %p conn %p", sk, conn);
-- sco_conn_put(sco_pi(sk)->conn);
++ if (conn) {
++ sco_pi(sk)->conn = NULL; // Disconnect the Socket from the conn reference
++ sco_conn_put(conn);
++ }
skb_queue_purge(&sk->sk_receive_queue);
skb_queue_purge(&sk->sk_write_queue);
}
2. Ensure that Socket references are cleared when SCO connections are released.The validity of conn->sk is no longer relied on in sco_conn_free because the association was actively disassociated when the Socket was released.
net/bluetooth/sco.c
static void sco_conn_free(struct kref *ref)
{
struct sco_conn *conn = container_of(ref, struct sco_conn, ref);
BT_DBG("conn %p", conn);
++ //Access to conn->sk was removed, and the Socket cleaned itself
-- if (conn->sk)
-- sco_pi(conn->sk)->conn = NULL;
if (conn->hcon) {
conn->hcon->sco_data = NULL;
hci_conn_drop(conn->hcon);
}
/* Ensure no more work items will run since hci_conn has been dropped */
disable_delayed_work_sync(&conn->timeout_work);
kfree(conn);
}
3.Adjust the connection disconnection logical sequence.In sco_conn_del, disconnect the Socket from the connection before releasing resources.
net/bluetooth/sco.c
static void sco_conn_del(struct hci_conn *hcon, int err)
{
struct sco_conn *conn = hcon->sco_data;
struct sock *sk;
conn = sco_conn_hold_unless_zero(conn);
if (!conn)
return;
BT_DBG("hcon %p conn %p, err %d", hcon, conn, err);
sco_conn_lock(conn);
sk = sco_sock_hold(conn);
sco_conn_unlock(conn);
sco_conn_put(conn);
if (!sk) {
sco_conn_put(conn);
return;
}
/* Kill socket */
lock_sock(sk);
sco_sock_clear_timer(sk);
sco_chan_del(sk, err);
release_sock(sk);
sock_put(sk);
++ conn->sk = NULL; // Ensure that conn no longer holds processed SKS
}
=========================================================================
I hope it helps.
Best regards
Jianzhou Zhao
xingwei lee
Zhizhuo Tang</strforexctzzchange@...mail.com></xrivendell7@...il.com></xnxc22xnxc22@...com>
Powered by blists - more mailing lists