CVE-2026-64434

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

Bluetooth: L2CAP: Fix UAF in channel timeout by holding conn ref

l2cap_chan_timeout() runs asynchronously and accesses chan->conn. If

the connection is torn down while the timer is running or pending,

chan->conn can be freed, leading to a use-after-free when the timer

worker attempts to lock conn->lock:

| BUG: KASAN: slab-use-after-free in instrument_atomic_read_write include/linux/instrumented.h:112 [inline]

| BUG: KASAN: slab-use-after-free in atomic_long_try_cmpxchg_acquire include/linux/atomic/atomic-instrumented.h:4456 [inline]

| BUG: KASAN: slab-use-after-free in __mutex_trylock_fast kernel/locking/mutex.c:161 [inline]

| BUG: KASAN: slab-use-after-free in mutex_lock+0x4f/0xa0 kernel/locking/mutex.c:318

| Write of size 8 at addr ffff8881298d9550 by task kworker/2:1/83

|

| CPU: 2 UID: 0 PID: 83 Comm: kworker/2:1 Not tainted 7.1.0-rc6-next-20260601-dirty #6 PREEMPT(full)

| Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014

| Workqueue: events l2cap_chan_timeout

| Call Trace:

| <TASK>

| instrument_atomic_read_write include/linux/instrumented.h:112 [inline]

| atomic_long_try_cmpxchg_acquire include/linux/atomic/atomic-instrumented.h:4456 [inline]

| __mutex_trylock_fast kernel/locking/mutex.c:161 [inline]

| mutex_lock+0x4f/0xa0 kernel/locking/mutex.c:318

| l2cap_chan_timeout+0x5d/0x1b0 net/bluetooth/l2cap_core.c:422

| process_one_work kernel/workqueue.c:3326 [inline]

| process_scheduled_works+0x7c8/0xfb0 kernel/workqueue.c:3409

| worker_thread+0x8a9/0xcf0 kernel/workqueue.c:3490

| kthread+0x346/0x430 kernel/kthread.c:436

| ret_from_fork+0x1a3/0x470 arch/x86/kernel/process.c:158

| ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245

| </TASK>

|

| Allocated by task 320:

| l2cap_conn_add+0xa7/0x820 net/bluetooth/l2cap_core.c:7075

| l2cap_connect_cfm+0xdb/0xd70 net/bluetooth/l2cap_core.c:7452

| hci_connect_cfm include/net/bluetooth/hci_core.h:2139 [inline]

| hci_remote_features_evt+0x52f/0x9f0 net/bluetooth/hci_event.c:3760

| hci_event_func net/bluetooth/hci_event.c:7796 [inline]

| hci_event_packet+0x561/0xa70 net/bluetooth/hci_event.c:7847

| hci_rx_work+0x370/0x890 net/bluetooth/hci_core.c:4040

| process_one_work kernel/workqueue.c:3326 [inline]

| process_scheduled_works+0x7c8/0xfb0 kernel/workqueue.c:3409

| worker_thread+0x8a9/0xcf0 kernel/workqueue.c:3490

| kthread+0x346/0x430 kernel/kthread.c:436

| ret_from_fork+0x1a3/0x470 arch/x86/kernel/process.c:158

| ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245

|

| Freed by task 322:

| hci_disconn_cfm include/net/bluetooth/hci_core.h:2154 [inline]

| hci_conn_hash_flush+0x101/0x1f0 net/bluetooth/hci_conn.c:2736

| hci_dev_close_sync+0x889/0xde0 net/bluetooth/hci_sync.c:5405

| hci_dev_do_close net/bluetooth/hci_core.c:502 [inline]

| hci_unregister_dev+0x1f7/0x370 net/bluetooth/hci_core.c:2679

| vhci_release+0x12a/0x180 drivers/bluetooth/hci_vhci.c:690

| __fput+0x369/0x890 fs/file_table.c:510

| task_work_run+0x160/0x1d0 kernel/task_work.c:233

| get_signal+0xf5b/0x1120 kernel/signal.c:2810

| arch_do_signal_or_restart+0x4d/0x600 arch/x86/kernel/signal.c:337

| __exit_to_user_mode_loop kernel/entry/common.c:64 [inline]

| exit_to_user_mode_loop+0x85/0x510 kernel/entry/common.c:98

| do_syscall_64+0x263/0x3d0 arch/x86/entry/syscall_64.c:100

| entry_SYSCALL_64_after_hwframe+0x77/0x7f

|

| The buggy address belongs to the object at ffff8881298d9400

| which belongs to the cache kmalloc-512 of size 512

| The buggy address is located 336 bytes inside of

| freed 512-byte region [ffff8881298d9400, ffff8881298d9600)

Fix it by having chan->conn hold a reference to l2cap_conn (via

l2cap_conn_get) when the channel is added to the connection, and

releasing it in the channel destructor. This ensures the l2cap_conn

remains alive as long as the channel exists.

A new FLAG_DEL channel flag is introduced to indicate that the ch

---truncated---