mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Paul Menzel <pmenzel@molgen.mpg.de>
To: Ivan Pravdin <ipravdin.official@gmail.com>
Cc: marcel@holtmann.org, johan.hedberg@gmail.com,
	luiz.dentz@gmail.com, linux-bluetooth@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	syzbot+ac3c79181f6aecc5120c@syzkaller.appspotmail.com
Subject: Re: [PATCH] Bluetooth: hci_devcd_dump: fix out-of-bounds via dev_coredumpv
Date: Fri, 18 Jul 2025 09:41:58 +0200	[thread overview]
Message-ID: <2cacbbf0-0e7b-410f-9ca1-b4542e0d51d4@molgen.mpg.de> (raw)
In-Reply-To: <20250717151051.195106-2-ipravdin.official@gmail.com>

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

      parent reply	other threads:[~2025-07-18  7:42 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-17 15:10 Ivan Pravdin
2025-07-17 18:50 ` patchwork-bot+bluetooth
2025-07-18  7:41 ` Paul Menzel [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2cacbbf0-0e7b-410f-9ca1-b4542e0d51d4@molgen.mpg.de \
    --to=pmenzel@molgen.mpg.de \
    --cc=ipravdin.official@gmail.com \
    --cc=johan.hedberg@gmail.com \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luiz.dentz@gmail.com \
    --cc=marcel@holtmann.org \
    --cc=syzbot+ac3c79181f6aecc5120c@syzkaller.appspotmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®