CVE-2022-49111

In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: Fix use after free in hci_send_acl

This fixes the following trace caused by receiving HCI_EV_DISCONN_PHY_LINK_COMPLETE which does call hci_conn_del without first checking if conn->type is in fact AMP_LINK and in case it is do properly cleanup upper layers with hci_disconn_cfm:

================================================================== BUG: KASAN: use-after-free in hci_send_acl+0xaba/0xc50 Read of size 8 at addr ffff88800e404818 by task bluetoothd/142

CPU: 0 PID: 142 Comm: bluetoothd Not tainted
5.17.0-rc5-00006-gda4022eeac1a #7
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
Call Trace:
 <TASK>
 dump_stack_lvl+0x45/0x59
 print_address_description.constprop.0+0x1f/0x150
 kasan_report.cold+0x7f/0x11b
 hci_send_acl+0xaba/0xc50
 l2cap_do_send+0x23f/0x3d0
 l2cap_chan_send+0xc06/0x2cc0
 l2cap_sock_sendmsg+0x201/0x2b0
 sock_sendmsg+0xdc/0x110
 sock_write_iter+0x20f/0x370
 do_iter_readv_writev+0x343/0x690
 do_iter_write+0x132/0x640
 vfs_writev+0x198/0x570
 do_writev+0x202/0x280
 do_syscall_64+0x38/0x90
 entry_SYSCALL_64_after_hwframe+0x44/0xae
RSP: 002b:00007ffce8a099b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000014
Code: 0f 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3
0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 14 00 00 00 0f 05
<48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 89 54 24 1c 48 89 74 24 10
RDX: 0000000000000001 RSI: 00007ffce8a099e0 RDI: 0000000000000015
RAX: ffffffffffffffda RBX: 00007ffce8a099e0 RCX: 00007f788fc3cf77
R10: 00007ffce8af7080 R11: 0000000000000246 R12: 000055e4ccf75580
RBP: 0000000000000015 R08: 0000000000000002 R09: 0000000000000001
</TASK>
R13: 000055e4ccf754a0 R14: 000055e4ccf75cd0 R15: 000055e4ccf4a6b0

Allocated by task 45:
    kasan_save_stack+0x1e/0x40
    __kasan_kmalloc+0x81/0xa0
    hci_chan_create+0x9a/0x2f0
    l2cap_conn_add.part.0+0x1a/0xdc0
    l2cap_connect_cfm+0x236/0x1000
    le_conn_complete_evt+0x15a7/0x1db0
    hci_le_conn_complete_evt+0x226/0x2c0
    hci_le_meta_evt+0x247/0x450
    hci_event_packet+0x61b/0xe90
    hci_rx_work+0x4d5/0xc50
    process_one_work+0x8fb/0x15a0
    worker_thread+0x576/0x1240
    kthread+0x29d/0x340
    ret_from_fork+0x1f/0x30

Freed by task 45:
    kasan_save_stack+0x1e/0x40
    kasan_set_track+0x21/0x30
    kasan_set_free_info+0x20/0x30
    __kasan_slab_free+0xfb/0x130
    kfree+0xac/0x350
    hci_conn_cleanup+0x101/0x6a0
    hci_conn_del+0x27e/0x6c0
    hci_disconn_phylink_complete_evt+0xe0/0x120
    hci_event_packet+0x812/0xe90
    hci_rx_work+0x4d5/0xc50
    process_one_work+0x8fb/0x15a0
    worker_thread+0x576/0x1240
    kthread+0x29d/0x340
    ret_from_fork+0x1f/0x30

The buggy address belongs to the object at ffff88800c0f0500
The buggy address is located 24 bytes inside of
which belongs to the cache kmalloc-128 of size 128
The buggy address belongs to the page:
128-byte region [ffff88800c0f0500, ffff88800c0f0580)
flags: 0x100000000000200(slab|node=0|zone=1)
page:00000000fe45cd86 refcount:1 mapcount:0
mapping:0000000000000000 index:0x0 pfn:0xc0f0
raw: 0000000000000000 0000000080100010 00000001ffffffff
0000000000000000
raw: 0100000000000200 ffffea00003a2c80 dead000000000004
ffff8880078418c0
page dumped because: kasan: bad access detected
ffff88800c0f0400: 00 00 00 00 00 00 00 00 00 00 00 00 00 fc fc fc
Memory state around the buggy address:
>ffff88800c0f0500: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff88800c0f0480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff88800c0f0580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc

—truncated—

Weakness

Referencing memory after it has been freed can cause a program to crash, use unexpected values, or execute code.

Affected Software

Extended Description

The use of previously-freed memory can have any number of adverse consequences, ranging from the corruption of valid data to the execution of arbitrary code, depending on the instantiation and timing of the flaw. The simplest way data corruption may occur involves the system’s reuse of the freed memory. Use-after-free errors have two common and sometimes overlapping causes:

In this scenario, the memory in question is allocated to another pointer validly at some point after it has been freed. The original pointer to the freed memory is used again and points to somewhere within the new allocation. As the data is changed, it corrupts the validly used memory; this induces undefined behavior in the process. If the newly allocated data happens to hold a class, in C++ for example, various function pointers may be scattered within the heap data. If one of these function pointers is overwritten with an address to valid shellcode, execution of arbitrary code can be achieved.

Potential Mitigations

References

• https://git.kernel.org/stable/c/2cc803804ec9a296b3156855d6c8c4ca1c6b84be
• https://git.kernel.org/stable/c/3803d896ddd97c7c16689a5381c0960040727647
• https://git.kernel.org/stable/c/4da302b90b96c309987eb9b37c8547f939f042d2
• https://git.kernel.org/stable/c/643a6c26bd32e339d00ad97b8822b6db009e803c
• https://git.kernel.org/stable/c/684e505406abaeabe0058e9776f9210bf2747953
• https://git.kernel.org/stable/c/b3c2ea1fd444b3bb7b82bfd2c3a45418f85c2502
• https://git.kernel.org/stable/c/c41de54b0a963e59e4dd04c029a4a6d73f45ef9c
• https://git.kernel.org/stable/c/d404765dffdbd8dcd14758695d0c96c52fb2e624
• https://git.kernel.org/stable/c/f63d24baff787e13b723d86fe036f84bdbc35045