linux-cve-announce - CVE-2022-49909: Bluetooth: L2CAP: fix use-after-free in l2cap_conn

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
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <2025050104-CVE-2022-49909-60e6@gregkh>
Date: Thu,  1 May 2025 16:11:39 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: linux-cve-announce@...r.kernel.org
Cc: Greg Kroah-Hartman <gregkh@...nel.org>
Subject: CVE-2022-49909: Bluetooth: L2CAP: fix use-after-free in l2cap_conn_del()

From: Greg Kroah-Hartman <gregkh@...nel.org>

Description
===========

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

Bluetooth: L2CAP: fix use-after-free in l2cap_conn_del()

When l2cap_recv_frame() is invoked to receive data, and the cid is
L2CAP_CID_A2MP, if the channel does not exist, it will create a channel.
However, after a channel is created, the hold operation of the channel
is not performed. In this case, the value of channel reference counting
is 1. As a result, after hci_error_reset() is triggered, l2cap_conn_del()
invokes the close hook function of A2MP to release the channel. Then
 l2cap_chan_unlock(chan) will trigger UAF issue.

The process is as follows:
Receive data:
l2cap_data_channel()
    a2mp_channel_create()  --->channel ref is 2
    l2cap_chan_put()       --->channel ref is 1

Triger event:
    hci_error_reset()
        hci_dev_do_close()
        ...
        l2cap_disconn_cfm()
            l2cap_conn_del()
                l2cap_chan_hold()    --->channel ref is 2
                l2cap_chan_del()     --->channel ref is 1
                a2mp_chan_close_cb() --->channel ref is 0, release channel
                l2cap_chan_unlock()  --->UAF of channel

The detailed Call Trace is as follows:
BUG: KASAN: use-after-free in __mutex_unlock_slowpath+0xa6/0x5e0
Read of size 8 at addr ffff8880160664b8 by task kworker/u11:1/7593
Workqueue: hci0 hci_error_reset
Call Trace:
 <TASK>
 dump_stack_lvl+0xcd/0x134
 print_report.cold+0x2ba/0x719
 kasan_report+0xb1/0x1e0
 kasan_check_range+0x140/0x190
 __mutex_unlock_slowpath+0xa6/0x5e0
 l2cap_conn_del+0x404/0x7b0
 l2cap_disconn_cfm+0x8c/0xc0
 hci_conn_hash_flush+0x11f/0x260
 hci_dev_close_sync+0x5f5/0x11f0
 hci_dev_do_close+0x2d/0x70
 hci_error_reset+0x9e/0x140
 process_one_work+0x98a/0x1620
 worker_thread+0x665/0x1080
 kthread+0x2e4/0x3a0
 ret_from_fork+0x1f/0x30
 </TASK>

Allocated by task 7593:
 kasan_save_stack+0x1e/0x40
 __kasan_kmalloc+0xa9/0xd0
 l2cap_chan_create+0x40/0x930
 amp_mgr_create+0x96/0x990
 a2mp_channel_create+0x7d/0x150
 l2cap_recv_frame+0x51b8/0x9a70
 l2cap_recv_acldata+0xaa3/0xc00
 hci_rx_work+0x702/0x1220
 process_one_work+0x98a/0x1620
 worker_thread+0x665/0x1080
 kthread+0x2e4/0x3a0
 ret_from_fork+0x1f/0x30

Freed by task 7593:
 kasan_save_stack+0x1e/0x40
 kasan_set_track+0x21/0x30
 kasan_set_free_info+0x20/0x30
 ____kasan_slab_free+0x167/0x1c0
 slab_free_freelist_hook+0x89/0x1c0
 kfree+0xe2/0x580
 l2cap_chan_put+0x22a/0x2d0
 l2cap_conn_del+0x3fc/0x7b0
 l2cap_disconn_cfm+0x8c/0xc0
 hci_conn_hash_flush+0x11f/0x260
 hci_dev_close_sync+0x5f5/0x11f0
 hci_dev_do_close+0x2d/0x70
 hci_error_reset+0x9e/0x140
 process_one_work+0x98a/0x1620
 worker_thread+0x665/0x1080
 kthread+0x2e4/0x3a0
 ret_from_fork+0x1f/0x30

Last potentially related work creation:
 kasan_save_stack+0x1e/0x40
 __kasan_record_aux_stack+0xbe/0xd0
 call_rcu+0x99/0x740
 netlink_release+0xe6a/0x1cf0
 __sock_release+0xcd/0x280
 sock_close+0x18/0x20
 __fput+0x27c/0xa90
 task_work_run+0xdd/0x1a0
 exit_to_user_mode_prepare+0x23c/0x250
 syscall_exit_to_user_mode+0x19/0x50
 do_syscall_64+0x42/0x80
 entry_SYSCALL_64_after_hwframe+0x63/0xcd

Second to last potentially related work creation:
 kasan_save_stack+0x1e/0x40
 __kasan_record_aux_stack+0xbe/0xd0
 call_rcu+0x99/0x740
 netlink_release+0xe6a/0x1cf0
 __sock_release+0xcd/0x280
 sock_close+0x18/0x20
 __fput+0x27c/0xa90
 task_work_run+0xdd/0x1a0
 exit_to_user_mode_prepare+0x23c/0x250
 syscall_exit_to_user_mode+0x19/0x50
 do_syscall_64+0x42/0x80
 entry_SYSCALL_64_after_hwframe+0x63/0xcd

The Linux kernel CVE team has assigned CVE-2022-49909 to this issue.


Affected and fixed versions
===========================

	Issue introduced in 4.9.326 with commit d255c861e268ba342e855244639a15f12d7a0bf2 and fixed in 4.9.333 with commit db4a0783ed78beb2ebaa32f5f785bfd79c580689
	Issue introduced in 4.14.291 with commit 5bb395334392891dffae5a0e8f37dbe1d70496c9 and fixed in 4.14.299 with commit 17c6164854f8bb80bf76f32b2c2f199c16b53703
	Issue introduced in 4.19.255 with commit bbd1fdb0e1adf827997a93bf108f20ede038e56e and fixed in 4.19.265 with commit 7f7bfdd9a9af3b12c33d9da9a012e7f4d5c91f4b
	Issue introduced in 5.4.209 with commit 098e07ef0059296e710a801cdbd74b59016e6624 and fixed in 5.4.224 with commit c1f594dddd9ffd747c39f49cc5b67a9b7677d2ab
	Issue introduced in 5.10.135 with commit de5d4654ac6c22b1be756fdf7db18471e7df01ea and fixed in 5.10.154 with commit d9ec6e2fbd4a565b2345d4852f586b7ae3ab41fd
	Issue introduced in 5.15.59 with commit f32d5615a78a1256c4f557ccc6543866e75d03f4 and fixed in 5.15.78 with commit a3a7b2ac64de232edb67279e804932cb42f0b52a
	Issue introduced in 5.19 with commit d0be8347c623e0ac4202a1d4e0373882821f56b0 and fixed in 6.0.8 with commit 8f7e4cf0694149a5d999d676ebd9ecf1b4cb2cc9
	Issue introduced in 5.19 with commit d0be8347c623e0ac4202a1d4e0373882821f56b0 and fixed in 6.1 with commit 0d0e2d032811280b927650ff3c15fe5020e82533
	Issue introduced in 5.18.16 with commit 59a55ec33a54a7179fa178f8aaf8b1cb8e63bd93

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2022-49909
will be updated if fixes are backported, please check that for the most
up to date information about this issue.


Affected files
==============

The file(s) affected by this issue are:
	net/bluetooth/l2cap_core.c


Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/db4a0783ed78beb2ebaa32f5f785bfd79c580689
	https://git.kernel.org/stable/c/17c6164854f8bb80bf76f32b2c2f199c16b53703
	https://git.kernel.org/stable/c/7f7bfdd9a9af3b12c33d9da9a012e7f4d5c91f4b
	https://git.kernel.org/stable/c/c1f594dddd9ffd747c39f49cc5b67a9b7677d2ab
	https://git.kernel.org/stable/c/d9ec6e2fbd4a565b2345d4852f586b7ae3ab41fd
	https://git.kernel.org/stable/c/a3a7b2ac64de232edb67279e804932cb42f0b52a
	https://git.kernel.org/stable/c/8f7e4cf0694149a5d999d676ebd9ecf1b4cb2cc9
	https://git.kernel.org/stable/c/0d0e2d032811280b927650ff3c15fe5020e82533