I have seen one patch to l2cap_chan_timeout() is discussed and approved to fix the use-after-free in function l2cap_chan_timeout(). https://lore.kernel.org/linux-bluetooth/20210602232348.766496-1-luiz.dentz@xxxxxxxxx/T/#u In fact, I recently found some similar crashes using syzkaller. It's just quite similar to the discussed one. Below is the crash log ================================================================== BUG: KASAN: use-after-free in l2cap_send_cmd+0x78d/0x810 net/bluetooth/l2cap_core.c:940 Read of size 1 at addr ffff8880042c2264 by task kworker/3:2/80 CPU: 3 PID: 80 Comm: kworker/3:2 Not tainted 5.11.11+ #7 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014 Workqueue: events l2cap_chan_timeout Call Trace: __dump_stack lib/dump_stack.c:79 [inline] dump_stack+0x1b9/0x22e lib/dump_stack.c:120 print_address_description+0x7b/0x3a0 mm/kasan/report.c:230 __kasan_report+0x14e/0x200 mm/kasan/report.c:396 kasan_report+0x47/0x60 mm/kasan/report.c:413 l2cap_send_cmd+0x78d/0x810 net/bluetooth/l2cap_core.c:940 l2cap_send_disconn_req+0x303/0x4c0 net/bluetooth/l2cap_core.c:1592 l2cap_chan_close+0x5d5/0xd10 net/bluetooth/l2cap_core.c:802 l2cap_chan_timeout+0xf9/0x1a0 net/bluetooth/l2cap_core.c:436 process_one_work+0x6df/0xf80 kernel/workqueue.c:2275 worker_thread+0xac1/0x1340 kernel/workqueue.c:2421 kthread+0x2fc/0x320 kernel/kthread.c:292 ret_from_fork+0x22/0x30 arch/x86/entry/entry_64.S:296 Allocated by task 125: kasan_save_stack mm/kasan/common.c:38 [inline] kasan_set_track mm/kasan/common.c:46 [inline] set_alloc_info mm/kasan/common.c:401 [inline] ____kasan_kmalloc+0xc6/0x100 mm/kasan/common.c:429 kasan_kmalloc include/linux/kasan.h:219 [inline] kmem_cache_alloc_trace+0x124/0x200 mm/slub.c:2919 kmalloc include/linux/slab.h:552 [inline] kzalloc include/linux/slab.h:682 [inline] hci_alloc_dev+0x4d/0x1ab0 net/bluetooth/hci_core.c:3643 __vhci_create_device drivers/bluetooth/hci_vhci.c:99 [inline] vhci_create_device+0x10e/0x510 drivers/bluetooth/hci_vhci.c:148 process_one_work+0x6df/0xf80 kernel/workqueue.c:2275 worker_thread+0xac1/0x1340 kernel/workqueue.c:2421 kthread+0x2fc/0x320 kernel/kthread.c:292 ret_from_fork+0x22/0x30 arch/x86/entry/entry_64.S:296 Last potentially related work creation: kasan_save_stack+0x27/0x50 mm/kasan/common.c:38 kasan_record_aux_stack+0xbd/0xe0 mm/kasan/generic.c:344 insert_work+0x4f/0x340 kernel/workqueue.c:1331 __queue_work+0x9cc/0xdb0 kernel/workqueue.c:1497 queue_work_on+0xd8/0x130 kernel/workqueue.c:1524 process_one_work+0x6df/0xf80 kernel/workqueue.c:2275 worker_thread+0xac1/0x1340 kernel/workqueue.c:2421 kthread+0x2fc/0x320 kernel/kthread.c:292 ret_from_fork+0x22/0x30 arch/x86/entry/entry_64.S:296 Second to last potentially related work creation: kasan_save_stack+0x27/0x50 mm/kasan/common.c:38 kasan_record_aux_stack+0xbd/0xe0 mm/kasan/generic.c:344 insert_work+0x4f/0x340 kernel/workqueue.c:1331 __queue_work+0x9cc/0xdb0 kernel/workqueue.c:1497 call_timer_fn+0x35/0x210 kernel/time/timer.c:1417 expire_timers+0x264/0x3a0 kernel/time/timer.c:1457 __run_timers+0x503/0x660 kernel/time/timer.c:1731 run_timer_softirq+0x19/0x30 kernel/time/timer.c:1744 __do_softirq+0x216/0x539 kernel/softirq.c:343 The buggy address belongs to the object at ffff8880042c2000 which belongs to the cache kmalloc-8k of size 8192 The buggy address is located 612 bytes inside of 8192-byte region [ffff8880042c2000, ffff8880042c4000) The buggy address belongs to the page: page:000000004e07f003 refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff8880042c2000 pfn:0x42c0 head:000000004e07f003 order:3 compound_mapcount:0 compound_pincount:0 flags: 0x100000000010200(slab|head) raw: 0100000000010200 ffffea000038e608 ffffea00003dfe08 ffff88800104d1c0 raw: ffff8880042c2000 0000000000010000 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff8880042c2100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8880042c2180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff8880042c2200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff8880042c2280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8880042c2300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================== The vulnerable code line is presented below static void l2cap_send_cmd(struct l2cap_conn *conn, u8 ident, u8 code, u16 len, void *data) { struct sk_buff *skb = l2cap_build_cmd(conn, code, ident, len, data); u8 flags; BT_DBG("code 0x%2.2x", code); if (!skb) return; /* Use NO_FLUSH if supported or we have an LE link (which does * not support auto-flushing packets) */ if (lmp_no_flush_capable(conn->hcon->hdev) || // { 1 } conn->hcon->type == LE_LINK) flags = ACL_START_NO_FLUSH; else flags = ACL_START; ...... } The mark-{ 1 } code will dereference hdev->features, which is caught by the KASan as UAF read. This means that when the l2cap_send_cmd() is called, the controller has been already removed and the hdev object has been released. The problem may be the l2cap_chan_timeout() function again. I guess this delayed work is not properly cancelled when the controller is detached. Perhaps additional checks need to be added in this function or another proper cancel_delayed_work() is required. Regards Lin Ma
