linux-kernel - [BUG] Bluetooth: use-after-free in l2cap_info

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <5c6629f6.1d1a1.19a95c0b5bf.Coremail.xudongjie25@mails.ucas.ac.cn>
Date: Tue, 18 Nov 2025 14:57:05 +0800 (GMT+08:00)
From: 许东洁 <xudongjie25@...ls.ucas.ac.cn>
To: marcel@...tmann.org, johan.hedberg@...il.com, luiz.dentz@...il.com
Cc: linux-bluetooth@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: [BUG] Bluetooth: use-after-free in l2cap_info_timeout during
 connection cleanup

Hello,

A use-after-free vulnerability was discovered in the Bluetooth L2CAP subsystem of Linux kernel 6.6.0 using the syzkaller fuzzing tool.

The issue involves a race condition during connection cleanup: when l2cap_conn_del starts cleaning up connection resources, if l2cap_info_timeout workqueue executes simultaneously on another CPU, it may access freed memory.

Specific mechanism:
- l2cap_conn_del function deletes HCI channels and cleans up connection state
- However, before calling cancel_delayed_work_sync to wait for info_timer completion, the connection data structures may have been partially destroyed
- Meanwhile, l2cap_info_timeout continues executing and accesses the hci_chan structure being cleaned up through the call chain
- This eventually leads to dereferencing an invalid pointer in skb_queue_tail

Crash signature:
BUG: unable to handle kernel NULL pointer dereference in skb_queue_tail

Call stack path:
l2cap_info_timeout -&gt; l2cap_conn_start -&gt; ... -&gt; hci_queue_acl -&gt; skb_queue_tail

Related materials are provided below:
Config file: https://github.com/j1akai/KConfigFuzz_bug/blob/main/x86/66-config
Additional fuzzing context: https://github.com/PLASSICAxu/OS-bug/tree/main/ea13e77411e2a197a1929ad0738d6d8d3e181823

Suggested approach: add reference count checking at the beginning of l2cap_info_timeout to ensure the connection remains valid throughout function execution.

Acknowledgments
Xu Dongjie
University of Chinese Academy of Sciences