Re: [PATCH 2/4] Bluetooth: coredump: Fix btmon heap-buffer-overflow

[Zijun Hu <zijun.hu@oss.qualcomm.com>]

On 9/14/2026 10:05 PM, Luiz Augusto von Dentz wrote:
>> Issue:
>> ERROR: AddressSanitizer: heap-buffer-overflow on address 0x51b00000065c at pc 0x7f50b987a029 bp 0x7ffde88dc8d0 sp 0x7ffde88dc088
>> READ of size 17916 at 0x51b00000065c thread T0
>>     #0 0x7f50b987a028 in write ../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:1096
>>     #1 0x5b4f3443ae3a in btsnoop_write ../src/shared/btsnoop.c:289
>>     #2 0x5b4f3429cbf0 in data_callback ../monitor/control.c:969
>>     #3 0x5b4f3444fa9d in mainloop_run ../src/shared/mainloop.c:104
>>     #4 0x5b4f34451da6 in mainloop_run_with_signal ../src/shared/mainloop-notify.c:196
>>     #5 0x5b4f342953fc in main ../monitor/main.c:303
>>     #6 0x7f50b8c2a1c9 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
>>     #7 0x7f50b8c2a28a in __libc_start_main_impl ../csu/libc-start.c:360
>>     #8 0x5b4f34295ed4 in _start (/usr/bin/btmon+0x29fed4) (BuildId: b41caafb24db693946c283eaea48112186863d2d)
> This probably needs to be fixed in btmon if it attempts to read past
> the buffer size. Also, since it now supports vendor packets that may

Agree, will fix on the btmon side.

> not be limited by HCI packet size, perhaps we should allocate based on
> the channel MTU which probably needs per-vendor configuration to allow
> collecting its vendor packets.

This issue has nothing to do with HCI_VENDOR_PKT (0xff).
This problem has likely existed for a long time across almost every vendor's devcoredump since controller's RAM size almost >= 1490
The root cause is that devcoredump data accumulated from MANY MANY packets is being sent as a SINGLE DIAG packet to monitor channel.