PT-2026-64655 · Linux · Linux
CVE-2026-64434
·
Publicado
2026-07-25
·
Atualizado
2026-07-25
Nenhuma
Não há classificações de severidade ou métricas disponíveis. Quando houver, atualizaremos as informações correspondentes na página.
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:
|
| 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
|
|
| 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---
Encontrou algum problema na descrição? Tem algo a acrescentar? Fique à vontade para nos escrever 👾
Identificadores relacionados
Produtos afetados
Linux