* [PATCH] Bluetooth: hci_devcd_dump: fix out-of-bounds via dev_coredumpv
@ 2025-07-17 15:10 Ivan Pravdin
2025-07-17 18:50 ` patchwork-bot+bluetooth
2025-07-18 7:41 ` Paul Menzel
0 siblings, 2 replies; 3+ messages in thread
From: Ivan Pravdin @ 2025-07-17 15:10 UTC (permalink / raw)
To: marcel, johan.hedberg, luiz.dentz, linux-bluetooth, linux-kernel
Cc: Ivan Pravdin, syzbot+ac3c79181f6aecc5120c
Currently both dev_coredumpv and skb_put_data in hci_devcd_dump use
hdev->dump.head. However, dev_coredumpv can free the buffer. From
dev_coredumpm_timeout documentation, which is used by dev_coredumpv:
> Creates a new device coredump for the given device. If a previous one hasn't
> been read yet, the new coredump is discarded. The data lifetime is determined
> by the device coredump framework and when it is no longer needed the @free
> function will be called to free the data.
If the data has not been read by the userspace yet, dev_coredumpv will
discard new buffer, freeing hdev->dump.head. This leads to
vmalloc-out-of-bounds error when skb_put_data tries to access
hdev->dump.head.
A crash report from syzbot illustrates this:
==================================================================
BUG: KASAN: vmalloc-out-of-bounds in skb_put_data
include/linux/skbuff.h:2752 [inline]
BUG: KASAN: vmalloc-out-of-bounds in hci_devcd_dump+0x142/0x240
net/bluetooth/coredump.c:258
Read of size 140 at addr ffffc90004ed5000 by task kworker/u9:2/5844
CPU: 1 UID: 0 PID: 5844 Comm: kworker/u9:2 Not tainted
6.14.0-syzkaller-10892-g4e82c87058f4 #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 02/12/2025
Workqueue: hci0 hci_devcd_timeout
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:408 [inline]
print_report+0xc3/0x670 mm/kasan/report.c:521
kasan_report+0xe0/0x110 mm/kasan/report.c:634
check_region_inline mm/kasan/generic.c:183 [inline]
kasan_check_range+0xef/0x1a0 mm/kasan/generic.c:189
__asan_memcpy+0x23/0x60 mm/kasan/shadow.c:105
skb_put_data include/linux/skbuff.h:2752 [inline]
hci_devcd_dump+0x142/0x240 net/bluetooth/coredump.c:258
hci_devcd_timeout+0xb5/0x2e0 net/bluetooth/coredump.c:413
process_one_work+0x9cc/0x1b70 kernel/workqueue.c:3238
process_scheduled_works kernel/workqueue.c:3319 [inline]
worker_thread+0x6c8/0xf10 kernel/workqueue.c:3400
kthread+0x3c2/0x780 kernel/kthread.c:464
ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:153
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
</TASK>
The buggy address ffffc90004ed5000 belongs to a vmalloc virtual mapping
Memory state around the buggy address:
ffffc90004ed4f00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
ffffc90004ed4f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
>ffffc90004ed5000: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
^
ffffc90004ed5080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
ffffc90004ed5100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
==================================================================
To avoid this issue, reorder dev_coredumpv to be called after
skb_put_data that does not free the data.
Reported-by: syzbot+ac3c79181f6aecc5120c@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=ac3c79181f6aecc5120c
Fixes: b257e02ecc46 ("HCI: coredump: Log devcd dumps into the monitor")
Tested-by: syzbot+ac3c79181f6aecc5120c@syzkaller.appspotmail.com
Signed-off-by: Ivan Pravdin <ipravdin.official@gmail.com>
---
Changes since v2:
* Updated subject line
* Updated comment to include more details about the issue
* Moved dev_coredumpv instead of using temporary buffer
Changes since v1:
* Changed subject prefix to Bluetooth:
[v2] https://lore.kernel.org/linux-bluetooth/20250716003726.124975-2-ipravdin.official@gmail.com/
[v1] https://lore.kernel.org/linux-bluetooth/20250614041910.219584-1-ipravdin.official@gmail.com/
net/bluetooth/coredump.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/bluetooth/coredump.c b/net/bluetooth/coredump.c
index 819eacb38762..720cb79adf96 100644
--- a/net/bluetooth/coredump.c
+++ b/net/bluetooth/coredump.c
@@ -249,15 +249,15 @@ static void hci_devcd_dump(struct hci_dev *hdev)
size = hdev->dump.tail - hdev->dump.head;
- /* Emit a devcoredump with the available data */
- dev_coredumpv(&hdev->dev, hdev->dump.head, size, GFP_KERNEL);
-
/* Send a copy to monitor as a diagnostic packet */
skb = bt_skb_alloc(size, GFP_ATOMIC);
if (skb) {
skb_put_data(skb, hdev->dump.head, size);
hci_recv_diag(hdev, skb);
}
+
+ /* Emit a devcoredump with the available data */
+ dev_coredumpv(&hdev->dev, hdev->dump.head, size, GFP_KERNEL);
}
static void hci_devcd_handle_pkt_complete(struct hci_dev *hdev,
--
2.45.2
^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [PATCH] Bluetooth: hci_devcd_dump: fix out-of-bounds via dev_coredumpv
2025-07-17 15:10 [PATCH] Bluetooth: hci_devcd_dump: fix out-of-bounds via dev_coredumpv Ivan Pravdin
@ 2025-07-17 18:50 ` patchwork-bot+bluetooth
2025-07-18 7:41 ` Paul Menzel
1 sibling, 0 replies; 3+ messages in thread
From: patchwork-bot+bluetooth @ 2025-07-17 18:50 UTC (permalink / raw)
To: Ivan Pravdin
Cc: marcel, johan.hedberg, luiz.dentz, linux-bluetooth, linux-kernel,
syzbot+ac3c79181f6aecc5120c
Hello:
This patch was applied to bluetooth/bluetooth-next.git (master)
by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:
On Thu, 17 Jul 2025 11:10:52 -0400 you wrote:
> Currently both dev_coredumpv and skb_put_data in hci_devcd_dump use
> hdev->dump.head. However, dev_coredumpv can free the buffer. From
> dev_coredumpm_timeout documentation, which is used by dev_coredumpv:
>
> > Creates a new device coredump for the given device. If a previous one hasn't
> > been read yet, the new coredump is discarded. The data lifetime is determined
> > by the device coredump framework and when it is no longer needed the @free
> > function will be called to free the data.
>
> [...]
Here is the summary with links:
- Bluetooth: hci_devcd_dump: fix out-of-bounds via dev_coredumpv
https://git.kernel.org/bluetooth/bluetooth-next/c/2215f5c93ed1
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] Bluetooth: hci_devcd_dump: fix out-of-bounds via dev_coredumpv
2025-07-17 15:10 [PATCH] Bluetooth: hci_devcd_dump: fix out-of-bounds via dev_coredumpv Ivan Pravdin
2025-07-17 18:50 ` patchwork-bot+bluetooth
@ 2025-07-18 7:41 ` Paul Menzel
1 sibling, 0 replies; 3+ messages in thread
From: Paul Menzel @ 2025-07-18 7:41 UTC (permalink / raw)
To: Ivan Pravdin
Cc: marcel, johan.hedberg, luiz.dentz, linux-bluetooth, linux-kernel,
syzbot+ac3c79181f6aecc5120c
Dear Ivan,
Thank you for your patch.
Am 17.07.25 um 17:10 schrieb Ivan Pravdin:
> Currently both dev_coredumpv and skb_put_data in hci_devcd_dump use
> hdev->dump.head. However, dev_coredumpv can free the buffer. From
> dev_coredumpm_timeout documentation, which is used by dev_coredumpv:
>
> > Creates a new device coredump for the given device. If a previous one hasn't
> > been read yet, the new coredump is discarded. The data lifetime is determined
> > by the device coredump framework and when it is no longer needed the @free
> > function will be called to free the data.
Should you resend, the lines do not need to be intended, that means the
> should be at the very beginning.
> If the data has not been read by the userspace yet, dev_coredumpv will
> discard new buffer, freeing hdev->dump.head. This leads to
> vmalloc-out-of-bounds error when skb_put_data tries to access
> hdev->dump.head.
>
> A crash report from syzbot illustrates this:
>
> ==================================================================
> BUG: KASAN: vmalloc-out-of-bounds in skb_put_data
> include/linux/skbuff.h:2752 [inline]
> BUG: KASAN: vmalloc-out-of-bounds in hci_devcd_dump+0x142/0x240
> net/bluetooth/coredump.c:258
> Read of size 140 at addr ffffc90004ed5000 by task kworker/u9:2/5844
>
> CPU: 1 UID: 0 PID: 5844 Comm: kworker/u9:2 Not tainted
> 6.14.0-syzkaller-10892-g4e82c87058f4 #0 PREEMPT(full)
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 02/12/2025
> Workqueue: hci0 hci_devcd_timeout
> 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:408 [inline]
> print_report+0xc3/0x670 mm/kasan/report.c:521
> kasan_report+0xe0/0x110 mm/kasan/report.c:634
> check_region_inline mm/kasan/generic.c:183 [inline]
> kasan_check_range+0xef/0x1a0 mm/kasan/generic.c:189
> __asan_memcpy+0x23/0x60 mm/kasan/shadow.c:105
> skb_put_data include/linux/skbuff.h:2752 [inline]
> hci_devcd_dump+0x142/0x240 net/bluetooth/coredump.c:258
> hci_devcd_timeout+0xb5/0x2e0 net/bluetooth/coredump.c:413
> process_one_work+0x9cc/0x1b70 kernel/workqueue.c:3238
> process_scheduled_works kernel/workqueue.c:3319 [inline]
> worker_thread+0x6c8/0xf10 kernel/workqueue.c:3400
> kthread+0x3c2/0x780 kernel/kthread.c:464
> ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:153
> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
> </TASK>
>
> The buggy address ffffc90004ed5000 belongs to a vmalloc virtual mapping
> Memory state around the buggy address:
> ffffc90004ed4f00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
> ffffc90004ed4f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
> >ffffc90004ed5000: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
> ^
> ffffc90004ed5080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
> ffffc90004ed5100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
> ==================================================================
>
> To avoid this issue, reorder dev_coredumpv to be called after
> skb_put_data that does not free the data.
>
> Reported-by: syzbot+ac3c79181f6aecc5120c@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=ac3c79181f6aecc5120c
> Fixes: b257e02ecc46 ("HCI: coredump: Log devcd dumps into the monitor")
> Tested-by: syzbot+ac3c79181f6aecc5120c@syzkaller.appspotmail.com
> Signed-off-by: Ivan Pravdin <ipravdin.official@gmail.com>
> ---
>
> Changes since v2:
> * Updated subject line
> * Updated comment to include more details about the issue
> * Moved dev_coredumpv instead of using temporary buffer
>
> Changes since v1:
> * Changed subject prefix to Bluetooth:
>
> [v2] https://lore.kernel.org/linux-bluetooth/20250716003726.124975-2-ipravdin.official@gmail.com/
> [v1] https://lore.kernel.org/linux-bluetooth/20250614041910.219584-1-ipravdin.official@gmail.com/
One minor thing, *v3* is missing in the tag in summary, so it’d be
[PATCH v3]. `git format-patch -v3` should accomplish this.
> net/bluetooth/coredump.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/net/bluetooth/coredump.c b/net/bluetooth/coredump.c
> index 819eacb38762..720cb79adf96 100644
> --- a/net/bluetooth/coredump.c
> +++ b/net/bluetooth/coredump.c
> @@ -249,15 +249,15 @@ static void hci_devcd_dump(struct hci_dev *hdev)
>
> size = hdev->dump.tail - hdev->dump.head;
>
> - /* Emit a devcoredump with the available data */
> - dev_coredumpv(&hdev->dev, hdev->dump.head, size, GFP_KERNEL);
> -
> /* Send a copy to monitor as a diagnostic packet */
> skb = bt_skb_alloc(size, GFP_ATOMIC);
> if (skb) {
> skb_put_data(skb, hdev->dump.head, size);
> hci_recv_diag(hdev, skb);
> }
> +
> + /* Emit a devcoredump with the available data */
> + dev_coredumpv(&hdev->dev, hdev->dump.head, size, GFP_KERNEL);
> }
>
> static void hci_devcd_handle_pkt_complete(struct hci_dev *hdev,
Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
Kind regards,
Paul
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2025-07-18 7:42 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-07-17 15:10 [PATCH] Bluetooth: hci_devcd_dump: fix out-of-bounds via dev_coredumpv Ivan Pravdin
2025-07-17 18:50 ` patchwork-bot+bluetooth
2025-07-18 7:41 ` Paul Menzel
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).