linux-kernel - [BUG] Bluetooth: slab-use-after-free in hci_core.c:hci_send

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: <AKkAKwAGJh0rblXOmD98sapq.1.1763206454879.Hmail.2200013188@stu.pku.edu.cn>
Date: Sat, 15 Nov 2025 19:34:14 +0800 (GMT+08:00)
From: 李天宇 <2200013188@....pku.edu.cn>
To: linux-kernel <linux-kernel@...r.kernel.org>
Cc: linux-bluetooth <linux-bluetooth@...r.kernel.org>, 
	"luiz.dentz" <luiz.dentz@...il.com>, 
	"johan.hedberg" <johan.hedberg@...il.com>, 
	marcel <marcel@...tmann.org>
Subject: [BUG] Bluetooth: slab-use-after-free in hci_core.c:hci_send_acl()

Hello,

A use-after-free bug was triggered in the Bluetooth subsystem when handling L2CAP connection setup sequences.
The kernel reports a slab-use-after-free in hci_send_acl() issue caused by l2cap_info_timeout() accessing a freed hci_chan object.

This bug was found via a fuzzing framework on Linux v6.6(x86_64, QEMU). Test environment, configuration, and relevant materials are provided below:

	Kernel source: https://www.kernel.org/pub/linux/kernel/v6.x/linux-6.6.tar.gz
	Config file: https://github.com/j1akai/KConfigFuzz_bug/raw/refs/heads/main/x86/66-config
	Kernel log: https://github.com/j1akai/KConfigFuzz_bug/raw/refs/heads/main/x86/crashes-part1/0094_aa5b436b78ce432eb9fa23bf14105889c0825990/x86_62_66_syzkaller_0901_6.6_yin/report0

The reports indicate that hci_chan was allocated in hci_chan_create() and later freed in hci_chan_cleanup(), while a pending L2CAP work queue callback (l2cap_info_timeout) continued to access this object and invoked hci_send_acl(), resulting in a use-after-free read. 
After checking relevant code on mainline, it seems though there are some additional checks, none of them involve checking whether hci_chan is empty.

I’m currently only reporting the issue to the community; the exact fix will likely need confirmation and review from the Bluetooth maintainers.