CVE-2026-64434

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: L2CAP: Fix UAF in channel timeout by holding conn ref<br /> <br /> l2cap_chan_timeout() runs asynchronously and accesses chan-&gt;conn. If<br /> the connection is torn down while the timer is running or pending,<br /> chan-&gt;conn can be freed, leading to a use-after-free when the timer<br /> worker attempts to lock conn-&gt;lock:<br /> <br /> | BUG: KASAN: slab-use-after-free in instrument_atomic_read_write include/linux/instrumented.h:112 [inline]<br /> | BUG: KASAN: slab-use-after-free in atomic_long_try_cmpxchg_acquire include/linux/atomic/atomic-instrumented.h:4456 [inline]<br /> | BUG: KASAN: slab-use-after-free in __mutex_trylock_fast kernel/locking/mutex.c:161 [inline]<br /> | BUG: KASAN: slab-use-after-free in mutex_lock+0x4f/0xa0 kernel/locking/mutex.c:318<br /> | Write of size 8 at addr ffff8881298d9550 by task kworker/2:1/83<br /> |<br /> | CPU: 2 UID: 0 PID: 83 Comm: kworker/2:1 Not tainted 7.1.0-rc6-next-20260601-dirty #6 PREEMPT(full)<br /> | Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014<br /> | Workqueue: events l2cap_chan_timeout<br /> | Call Trace:<br /> | <br /> | instrument_atomic_read_write include/linux/instrumented.h:112 [inline]<br /> | atomic_long_try_cmpxchg_acquire include/linux/atomic/atomic-instrumented.h:4456 [inline]<br /> | __mutex_trylock_fast kernel/locking/mutex.c:161 [inline]<br /> | mutex_lock+0x4f/0xa0 kernel/locking/mutex.c:318<br /> | l2cap_chan_timeout+0x5d/0x1b0 net/bluetooth/l2cap_core.c:422<br /> | process_one_work kernel/workqueue.c:3326 [inline]<br /> | process_scheduled_works+0x7c8/0xfb0 kernel/workqueue.c:3409<br /> | worker_thread+0x8a9/0xcf0 kernel/workqueue.c:3490<br /> | kthread+0x346/0x430 kernel/kthread.c:436<br /> | ret_from_fork+0x1a3/0x470 arch/x86/kernel/process.c:158<br /> | ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245<br /> | <br /> |<br /> | Allocated by task 320:<br /> | l2cap_conn_add+0xa7/0x820 net/bluetooth/l2cap_core.c:7075<br /> | l2cap_connect_cfm+0xdb/0xd70 net/bluetooth/l2cap_core.c:7452<br /> | hci_connect_cfm include/net/bluetooth/hci_core.h:2139 [inline]<br /> | hci_remote_features_evt+0x52f/0x9f0 net/bluetooth/hci_event.c:3760<br /> | hci_event_func net/bluetooth/hci_event.c:7796 [inline]<br /> | hci_event_packet+0x561/0xa70 net/bluetooth/hci_event.c:7847<br /> | hci_rx_work+0x370/0x890 net/bluetooth/hci_core.c:4040<br /> | process_one_work kernel/workqueue.c:3326 [inline]<br /> | process_scheduled_works+0x7c8/0xfb0 kernel/workqueue.c:3409<br /> | worker_thread+0x8a9/0xcf0 kernel/workqueue.c:3490<br /> | kthread+0x346/0x430 kernel/kthread.c:436<br /> | ret_from_fork+0x1a3/0x470 arch/x86/kernel/process.c:158<br /> | ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245<br /> |<br /> | Freed by task 322:<br /> | hci_disconn_cfm include/net/bluetooth/hci_core.h:2154 [inline]<br /> | hci_conn_hash_flush+0x101/0x1f0 net/bluetooth/hci_conn.c:2736<br /> | hci_dev_close_sync+0x889/0xde0 net/bluetooth/hci_sync.c:5405<br /> | hci_dev_do_close net/bluetooth/hci_core.c:502 [inline]<br /> | hci_unregister_dev+0x1f7/0x370 net/bluetooth/hci_core.c:2679<br /> | vhci_release+0x12a/0x180 drivers/bluetooth/hci_vhci.c:690<br /> | __fput+0x369/0x890 fs/file_table.c:510<br /> | task_work_run+0x160/0x1d0 kernel/task_work.c:233<br /> | get_signal+0xf5b/0x1120 kernel/signal.c:2810<br /> | arch_do_signal_or_restart+0x4d/0x600 arch/x86/kernel/signal.c:337<br /> | __exit_to_user_mode_loop kernel/entry/common.c:64 [inline]<br /> | exit_to_user_mode_loop+0x85/0x510 kernel/entry/common.c:98<br /> | do_syscall_64+0x263/0x3d0 arch/x86/entry/syscall_64.c:100<br /> | entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> |<br /> | The buggy address belongs to the object at ffff8881298d9400<br /> | which belongs to the cache kmalloc-512 of size 512<br /> | The buggy address is located 336 bytes inside of<br /> | freed 512-byte region [ffff8881298d9400, ffff8881298d9600)<br /> <br /> Fix it by having chan-&gt;conn hold a reference to l2cap_conn (via<br /> l2cap_conn_get) when the channel is added to the connection, and<br /> releasing it in the channel destructor. This ensures the l2cap_conn<br /> remains alive as long as the channel exists.<br /> <br /> A new FLAG_DEL channel flag is introduced to indicate that the ch<br /> ---truncated---