CVE-2025-39860

Bluetooth: Fix use-after-free in l2cap_sock_cleanup_listen()

HIGH
7.8
CVSS Score
Published: September 19, 2025 at 03:26 PM UTC
Updated: October 19, 2026 at 09:10 PM UTC
15 products affected across 3 vendorsLinux KernelDebian LinuxRUGGEDCOM RST2428P Firmware

Using Linux by Linux?

Get instant alerts when new vulnerabilities affect Linux - before attackers find them.

Real-time alertsTrack your software stackFree plan available
Severity
HIGH7.8
Exploit prediction
EPSS 0.2%
SSVC
No known exploit

Description

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Fix use-after-free in l2cap_sock_cleanup_listen() syzbot reported the splat below without a repro. In the splat, a single thread calling bt_accept_dequeue() freed sk and touched it after that. The root cause would be the racy l2cap_sock_cleanup_listen() call added by the cited commit. bt_accept_dequeue() is called under lock_sock() except for l2cap_sock_release(). Two threads could see the same socket during the list iteration in bt_accept_dequeue(): CPU1 CPU2 (close()) ---- ---- sock_hold(sk) sock_hold(sk); lock_sock(sk) <-- block close() sock_put(sk) bt_accept_unlink(sk) sock_put(sk) <-- refcnt by bt_accept_enqueue() release_sock(sk) lock_sock(sk) sock_put(sk) bt_accept_unlink(sk) sock_put(sk) <-- last refcnt bt_accept_unlink(sk) <-- UAF Depending on the timing, the other thread could show up in the "Freed by task" part. Let's call l2cap_sock_cleanup_listen() under lock_sock() in l2cap_sock_release(). [0]: BUG: KASAN: slab-use-after-free in debug_spin_lock_before kernel/locking/spinlock_debug.c:86 [inline] BUG: KASAN: slab-use-after-free in do_raw_spin_lock+0x26f/0x2b0 kernel/locking/spinlock_debug.c:115 Read of size 4 at addr ffff88803b7eb1c4 by task syz.5.3276/16995 CPU: 3 UID: 0 PID: 16995 Comm: syz.5.3276 Not tainted syzkaller #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xcd/0x630 mm/kasan/report.c:482 kasan_report+0xe0/0x110 mm/kasan/report.c:595 debug_spin_lock_before kernel/locking/spinlock_debug.c:86 [inline] do_raw_spin_lock+0x26f/0x2b0 kernel/locking/spinlock_debug.c:115 spin_lock_bh include/linux/spinlock.h:356 [inline] release_sock+0x21/0x220 net/core/sock.c:3746 bt_accept_dequeue+0x505/0x600 net/bluetooth/af_bluetooth.c:312 l2cap_sock_cleanup_listen+0x5c/0x2a0 net/bluetooth/l2cap_sock.c:1451 l2cap_sock_release+0x5c/0x210 net/bluetooth/l2cap_sock.c:1425 __sock_release+0xb3/0x270 net/socket.c:649 sock_close+0x1c/0x30 net/socket.c:1439 __fput+0x3ff/0xb70 fs/file_table.c:468 task_work_run+0x14d/0x240 kernel/task_work.c:227 resume_user_mode_work include/linux/resume_user_mode.h:50 [inline] exit_to_user_mode_loop+0xeb/0x110 kernel/entry/common.c:43 exit_to_user_mode_prepare include/linux/irq-entry-common.h:225 [inline] syscall_exit_to_user_mode_work include/linux/entry-common.h:175 [inline] syscall_exit_to_user_mode include/linux/entry-common.h:210 [inline] do_syscall_64+0x3f6/0x4c0 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f2accf8ebe9 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffdb6cb1378 EFLAGS: 00000246 ORIG_RAX: 00000000000001b4 RAX: 0000000000000000 RBX: 00000000000426fb RCX: 00007f2accf8ebe9 RDX: 0000000000000000 RSI: 000000000000001e RDI: 0000000000000003 RBP: 00007f2acd1b7da0 R08: 0000000000000001 R09: 00000012b6cb166f R10: 0000001b30e20000 R11: 0000000000000246 R12: 00007f2acd1b609c R13: 00007f2acd1b6090 R14: ffffffffffffffff R15: 00007ffdb6cb1490 </TASK> Allocated by task 5326: kasan_save_stack+0x33/0x60 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:388 [inline] __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:405 kasan_kmalloc include/linux/kasan.h:260 [inline] __do_kmalloc_node mm/slub.c:4365 [inline] __kmalloc_nopro ---truncated---

Affected

Our own answer: ranges merged, affected separated from platform-only, with confidence and review flags.

4.14.322 ≤ v < 4.154.19.291 ≤ v < 4.205.10.190 ≤ v < 5.10.2435.15.126 ≤ v < 5.15.1925.4.253 ≤ v < 5.4.2996.1.45 ≤ v < 6.1.1516.13 ≤ v < 6.16.66.4.10 ≤ v < 6.6.1056.7 ≤ v < 6.12.4610426afe65c8bf7b24dd0c7be4dcc65f86fc99f91728137b33c00d5a2b5110ed7aafb42e7c32e4a129fac18499332211b2615ade356e2bd8b3269f984.14.3224.19.2915.10.1905.15.1265.4.25351822644a047eac2310fab0799b64e3430b5a1116.1.456.176.17 rc16.17 rc26.17 rc36.17 rc46.4.106f87c96216bc5cd1094c23492274f77f1d5dd3b82cdb2ccbe43337798393369f0ceb98699fe6037a2da00d1ea1abfb04f846638e210b5b5166e3c9cfbe5a2fed8156cc19eb3b956602b0a1dd46a302d
Vendor states this is fixed in 2ca99fc3512a8074de20ee52a87b492dfcc41a4d (fixed)
Vendor states this is fixed in 306b0991413b482dbf5585b423022123bb505966 (fixed)
Vendor states this is fixed in 3dff390f55ccd9ce12e91233849769b5312180c2 (fixed)
Vendor states this is fixed in 47f6090bcf75c369695d21c3f179db8a56bbbd49 (fixed)
Vendor states this is fixed in 6077d16b5c0f65d571eee709de2f0541fb5ef0ca (fixed)
Vendor states this is fixed in 83e1d9892ef51785cf0760b7681436760dda435a (fixed)
Vendor states this is fixed in 862c628108562d8c7a516a900034823b381d3cba (fixed)
Vendor states this is fixed in 964cbb198f9c46c2b2358cd1faffc04c1e8248cf (fixed)
Affected range stops below 4.15, so it looks safe — our inference, not a vendor statement
Affected range stops below 4.20, so it looks safe — our inference, not a vendor statement
Vendor states this is fixed in 5.10.243 (unaffected)
Vendor states this is fixed in 5.15.192 (unaffected)
Vendor states this is fixed in 5.4.299 (unaffected)
Vendor states this is fixed in 6.1.151 (unaffected)
Vendor states this is fixed in 6.12.46 (unaffected)
Vendor states this is fixed in 6.16.6 (unaffected)
Vendor states this is fixed in 6.17 (unaffected)
Vendor states this is fixed in 6.5 (unaffected)
Vendor states this is fixed in 6.6.105 (unaffected)
v < V3.3
Affected range stops below V3.3, so it looks safe — our inference, not a vendor statement
v < V3.3
Affected range stops below V3.3, so it looks safe — our inference, not a vendor statement
v < V3.3
Affected range stops below V3.3, so it looks safe — our inference, not a vendor statement
v < V3.3
Affected range stops below V3.3, so it looks safe — our inference, not a vendor statement
v < V3.3
Affected range stops below V3.3, so it looks safe — our inference, not a vendor statement
v < V3.3
Affected range stops below V3.3, so it looks safe — our inference, not a vendor statement
v < V3.3
Affected range stops below V3.3, so it looks safe — our inference, not a vendor statement
v < V3.3
Affected range stops below V3.3, so it looks safe — our inference, not a vendor statement

SSVC — Action Prioritization

SSVCNo known exploitNot automatableTotal impact

SSVC signals action urgency (what to patch first), separate from CVSS which measures severity.

CVSS

Attack Vector
LOCAL
Complexity
LOW
Privileges
LOW
User Interaction
NONE
Scope
UNCHANGED
Confidentiality
HIGH
Integrity
HIGH
Availability
HIGH
Vector?

Quick Info

StatusMODIFIED
CWE
CWE-416

Get alerted

Stop reading CVE feeds looking for your own stack

Track the products you run and VulnTracker tells you when a new CVE affects them — with what is known about fixing it, and nothing about the rest.

Free plan, no card