forked from micropython/micropython
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add new USB PID for Feather M0 with CDC + MSC #8
Comments
Fixed in 90bf13e |
jepler
added a commit
to jepler/circuitpython
that referenced
this issue
Oct 1, 2020
It was incorrect to NULL out the pointer to our heap allocated buffer in `reset`, because subsequent to framebuffer_reset, but while the heap was still active, we could call `get_bufinfo` again, leading to a fresh allocation on the heap that is about to be destroyed. Typical stack trace: ``` #1 0x0006c368 in sharpdisplay_framebuffer_get_bufinfo #2 0x0006ad6e in _refresh_display #3 0x0006b168 in framebufferio_framebufferdisplay_background #4 0x00069d22 in displayio_background adafruit#5 0x00045496 in supervisor_background_tasks adafruit#6 0x000446e8 in background_callback_run_all adafruit#7 0x00045546 in supervisor_run_background_tasks_if_tick adafruit#8 0x0005b042 in common_hal_neopixel_write adafruit#9 0x00044c4c in clear_temp_status adafruit#10 0x000497de in spi_flash_flush_keep_cache adafruit#11 0x00049a66 in supervisor_external_flash_flush adafruit#12 0x00044b22 in supervisor_flash_flush adafruit#13 0x0004490e in filesystem_flush adafruit#14 0x00043e18 in cleanup_after_vm adafruit#15 0x0004414c in run_repl adafruit#16 0x000441ce in main ``` When this happened -- which was inconsistent -- the display would keep some heap allocation across reset which is exactly what we need to avoid. NULLing the pointer in reconstruct follows what RGBMatrix does, and that code is a bit more battle-tested anyway. If I had a motivation for structuring the SharpMemory code differently, I can no longer recall it. Testing performed: Ran my complicated calculator program over multiple iterations without observing signs of heap corruption. Closes: adafruit#3473
jepler
added a commit
to jepler/circuitpython
that referenced
this issue
May 10, 2021
asan considers that memcmp(p, q, N) is permitted to access N bytes at each of p and q, even for values of p and q that have a difference earlier. Accessing additional values is frequently done in practice, reading 4 or more bytes from each input at a time for efficiency, so when completing "non_exist<TAB>" in the repl, this causes a diagnostic: ``` ==16938==ERROR: AddressSanitizer: global-buffer-overflow on address 0x555555cd8dc8 at pc 0x7ffff726457b bp 0x7fffffffda20 sp 0x7fffffffd1d0 READ of size 9 at 0x555555cd8dc8 thread T0 #0 0x7ffff726457a (/usr/lib/x86_64-linux-gnu/libasan.so.5+0xb857a) #1 0x555555b0e82a in mp_repl_autocomplete ../../py/repl.c:301 #2 0x555555c89585 in readline_process_char ../../lib/mp-readline/readline.c:225 #3 0x555555c8ac6e in readline ../../lib/mp-readline/readline.c:513 #4 0x555555b8dcbd in do_repl /home/jepler/src/micropython/ports/unix/main.c:194 adafruit#5 0x555555b90859 in main_ /home/jepler/src/micropython/ports/unix/main.c:673 adafruit#6 0x555555b90a3a in main /home/jepler/src/micropython/ports/unix/main.c:436 adafruit#7 0x7ffff619a09a in __libc_start_main ../csu/libc-start.c:308 adafruit#8 0x55555595fd69 in _start (/home/jepler/src/micropython/ports/unix/micropython-coverage+0x40bd69) 0x555555cd8dc8 is located 0 bytes to the right of global variable 'import_str' defined in '../../py/repl.c:285:23' (0x555555cd8dc0) of size 8 'import_str' is ascii string 'import ' SUMMARY: AddressSanitizer: global-buffer-overflow (/usr/lib/x86_64-linux-gnu/libasan.so.5+0xb857a) Shadow bytes around the buggy address: 0x0aab2ab93160: 04 f9 f9 f9 f9 f9 f9 f9 04 f9 f9 f9 f9 f9 f9 f9 0x0aab2ab93170: 05 f9 f9 f9 f9 f9 f9 f9 04 f9 f9 f9 f9 f9 f9 f9 0x0aab2ab93180: 06 f9 f9 f9 f9 f9 f9 f9 06 f9 f9 f9 f9 f9 f9 f9 0x0aab2ab93190: 05 f9 f9 f9 f9 f9 f9 f9 00 00 f9 f9 f9 f9 f9 f9 0x0aab2ab931a0: 00 00 00 00 00 00 00 00 04 f9 f9 f9 f9 f9 f9 f9 =>0x0aab2ab931b0: 00 00 00 00 00 00 00 00 00[f9]f9 f9 f9 f9 f9 f9 0x0aab2ab931c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0aab2ab931d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0aab2ab931e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 04 f9 0x0aab2ab931f0: f9 f9 f9 f9 00 00 00 00 00 00 00 00 00 f9 f9 f9 0x0aab2ab93200: f9 f9 f9 f9 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 Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb ==16938==ABORTING ```
jepler
added a commit
to jepler/circuitpython
that referenced
this issue
May 10, 2021
asan considers that memcmp(p, q, N) is permitted to access N bytes at each of p and q, even for values of p and q that have a difference earlier. Accessing additional values is frequently done in practice, reading 4 or more bytes from each input at a time for efficiency, so when completing "non_exist<TAB>" in the repl, this causes a diagnostic: ``` ==16938==ERROR: AddressSanitizer: global-buffer-overflow on address 0x555555cd8dc8 at pc 0x7ffff726457b bp 0x7fffffffda20 sp 0x7fffffffd1d0 READ of size 9 at 0x555555cd8dc8 thread T0 #0 0x7ffff726457a (/usr/lib/x86_64-linux-gnu/libasan.so.5+0xb857a) #1 0x555555b0e82a in mp_repl_autocomplete ../../py/repl.c:301 #2 0x555555c89585 in readline_process_char ../../lib/mp-readline/readline.c:225 #3 0x555555c8ac6e in readline ../../lib/mp-readline/readline.c:513 #4 0x555555b8dcbd in do_repl /home/jepler/src/micropython/ports/unix/main.c:194 adafruit#5 0x555555b90859 in main_ /home/jepler/src/micropython/ports/unix/main.c:673 adafruit#6 0x555555b90a3a in main /home/jepler/src/micropython/ports/unix/main.c:436 adafruit#7 0x7ffff619a09a in __libc_start_main ../csu/libc-start.c:308 adafruit#8 0x55555595fd69 in _start (/home/jepler/src/micropython/ports/unix/micropython-coverage+0x40bd69) 0x555555cd8dc8 is located 0 bytes to the right of global variable 'import_str' defined in '../../py/repl.c:285:23' (0x555555cd8dc0) of size 8 'import_str' is ascii string 'import ' SUMMARY: AddressSanitizer: global-buffer-overflow (/usr/lib/x86_64-linux-gnu/libasan.so.5+0xb857a) Shadow bytes around the buggy address: 0x0aab2ab93160: 04 f9 f9 f9 f9 f9 f9 f9 04 f9 f9 f9 f9 f9 f9 f9 0x0aab2ab93170: 05 f9 f9 f9 f9 f9 f9 f9 04 f9 f9 f9 f9 f9 f9 f9 0x0aab2ab93180: 06 f9 f9 f9 f9 f9 f9 f9 06 f9 f9 f9 f9 f9 f9 f9 0x0aab2ab93190: 05 f9 f9 f9 f9 f9 f9 f9 00 00 f9 f9 f9 f9 f9 f9 0x0aab2ab931a0: 00 00 00 00 00 00 00 00 04 f9 f9 f9 f9 f9 f9 f9 =>0x0aab2ab931b0: 00 00 00 00 00 00 00 00 00[f9]f9 f9 f9 f9 f9 f9 0x0aab2ab931c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0aab2ab931d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0aab2ab931e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 04 f9 0x0aab2ab931f0: f9 f9 f9 f9 00 00 00 00 00 00 00 00 00 f9 f9 f9 0x0aab2ab93200: f9 f9 f9 f9 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 Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb ==16938==ABORTING ``` Signed-off-by: Jeff Epler <jepler@gmail.com>
jepler
added a commit
to jepler/circuitpython
that referenced
this issue
May 10, 2021
asan considers that memcmp(p, q, N) is permitted to access N bytes at each of p and q, even for values of p and q that have a difference earlier. Accessing additional values is frequently done in practice, reading 4 or more bytes from each input at a time for efficiency, so when completing "non_exist<TAB>" in the repl, this causes a diagnostic: ``` ==16938==ERROR: AddressSanitizer: global-buffer-overflow on address 0x555555cd8dc8 at pc 0x7ffff726457b bp 0x7fffffffda20 sp 0x7fff READ of size 9 at 0x555555cd8dc8 thread T0 #0 0x7ffff726457a (/usr/lib/x86_64-linux-gnu/libasan.so.5+0xb857a) #1 0x555555b0e82a in mp_repl_autocomplete ../../py/repl.c:301 #2 0x555555c89585 in readline_process_char ../../lib/mp-readline/re #3 0x555555c8ac6e in readline ../../lib/mp-readline/readline.c:513 #4 0x555555b8dcbd in do_repl /home/jepler/src/micropython/ports/uni adafruit#5 0x555555b90859 in main_ /home/jepler/src/micropython/ports/unix/ adafruit#6 0x555555b90a3a in main /home/jepler/src/micropython/ports/unix/m adafruit#7 0x7ffff619a09a in __libc_start_main ../csu/libc-start.c:308 adafruit#8 0x55555595fd69 in _start (/home/jepler/src/micropython/ports/uni 0x555555cd8dc8 is located 0 bytes to the right of global variable 'import_str' defined in '../../py/repl.c:285:23' (0x555555cd8dc0) of size 8 'import_str' is ascii string 'import ' ``` Signed-off-by: Jeff Epler <jepler@gmail.com>
jepler
added a commit
to jepler/circuitpython
that referenced
this issue
May 10, 2021
asan considers that memcmp(p, q, N) is permitted to access N bytes at each of p and q, even for values of p and q that have a difference earlier. Accessing additional values is frequently done in practice, reading 4 or more bytes from each input at a time for efficiency, so when completing "non_exist<TAB>" in the repl, this causes a diagnostic: ``` ==16938==ERROR: AddressSanitizer: global-buffer-overflow on address 0x555555cd8dc8 at pc 0x7ffff726457b bp 0x7fffffffda20 sp 0x7fff READ of size 9 at 0x555555cd8dc8 thread T0 #0 0x7ffff726457a (/usr/lib/x86_64-linux-gnu/libasan.so.5+0xb857a) #1 0x555555b0e82a in mp_repl_autocomplete ../../py/repl.c:301 #2 0x555555c89585 in readline_process_char ../../lib/mp-readline/re #3 0x555555c8ac6e in readline ../../lib/mp-readline/readline.c:513 #4 0x555555b8dcbd in do_repl /home/jepler/src/micropython/ports/uni adafruit#5 0x555555b90859 in main_ /home/jepler/src/micropython/ports/unix/ adafruit#6 0x555555b90a3a in main /home/jepler/src/micropython/ports/unix/m adafruit#7 0x7ffff619a09a in __libc_start_main ../csu/libc-start.c:308 adafruit#8 0x55555595fd69 in _start (/home/jepler/src/micropython/ports/uni 0x555555cd8dc8 is located 0 bytes to the right of global variable 'import_str' defined in '../../py/repl.c:285:23' (0x555555cd8dc0) of size 8 'import_str' is ascii string 'import ' ``` Signed-off-by: Jeff Epler <jepler@gmail.com>
jepler
added a commit
to jepler/circuitpython
that referenced
this issue
Jun 8, 2021
asan considers that memcmp(p, q, N) is permitted to access N bytes at each of p and q, even for values of p and q that have a difference earlier. Accessing additional values is frequently done in practice, reading 4 or more bytes from each input at a time for efficiency, so when completing "non_exist<TAB>" in the repl, this causes a diagnostic: ==16938==ERROR: AddressSanitizer: global-buffer-overflow on address 0x555555cd8dc8 at pc 0x7ffff726457b bp 0x7fffffffda20 sp 0x7fff READ of size 9 at 0x555555cd8dc8 thread T0 #0 0x7ffff726457a (/usr/lib/x86_64-linux-gnu/libasan.so.5+0xb857a) #1 0x555555b0e82a in mp_repl_autocomplete ../../py/repl.c:301 #2 0x555555c89585 in readline_process_char ../../lib/mp-readline/re #3 0x555555c8ac6e in readline ../../lib/mp-readline/readline.c:513 #4 0x555555b8dcbd in do_repl /home/jepler/src/micropython/ports/uni adafruit#5 0x555555b90859 in main_ /home/jepler/src/micropython/ports/unix/ adafruit#6 0x555555b90a3a in main /home/jepler/src/micropython/ports/unix/m adafruit#7 0x7ffff619a09a in __libc_start_main ../csu/libc-start.c:308 adafruit#8 0x55555595fd69 in _start (/home/jepler/src/micropython/ports/uni 0x555555cd8dc8 is located 0 bytes to the right of global variable 'import_str' defined in '../../py/repl.c:285:23' (0x555555cd8dc0) of size 8 'import_str' is ascii string 'import ' Signed-off-by: Jeff Epler <jepler@gmail.com>
cwalther
pushed a commit
to cwalther/circuitpython
that referenced
this issue
Jun 1, 2024
Although the original motivation given for the workaround[1] is correct, nlr.o and nlrthumb.o are linked with a small enough distance that the problem does not occur, and the workaround isn't necessary. The distance between the b instruction and its target (nlr_push_tail) is just 64 bytes[2], well within the ±2046 byte range addressable by an unconditional branch instruction in Thumb mode. The workaround induces a relocation in the text section (textrel), which isn't supported everywhere, notably not on musl-libc[3], where it causes a crash on start-up. With the workaround removed, micropython works on an ARMv5T Linux system built with musl-libc. This commit changes nlrthumb.c to use a direct jump by default, but leaves the long jump workaround as an option for those cases where it's actually needed. [1]: commit dd376a2 Author: Damien George <damien.p.george@gmail.com> Date: Fri Sep 1 15:25:29 2017 +1000 py/nlrthumb: Get working again on standard Thumb arch (ie not Thumb2). "b" on Thumb might not be long enough for the jump to nlr_push_tail so it must be done indirectly. [2]: Excerpt from objdump -d micropython: 000095c4 <nlr_push_tail>: 95c4: b510 push {r4, lr} 95c6: 0004 movs r4, r0 95c8: f02d fd42 bl 37050 <mp_thread_get_state> 95cc: 6943 ldr r3, [r0, adafruit#20] 95ce: 6023 str r3, [r4, #0] 95d0: 6144 str r4, [r0, adafruit#20] 95d2: 2000 movs r0, #0 95d4: bd10 pop {r4, pc} 000095d6 <nlr_pop>: 95d6: b510 push {r4, lr} 95d8: f02d fd3a bl 37050 <mp_thread_get_state> 95dc: 6943 ldr r3, [r0, adafruit#20] 95de: 681b ldr r3, [r3, #0] 95e0: 6143 str r3, [r0, adafruit#20] 95e2: bd10 pop {r4, pc} 000095e4 <nlr_push>: 95e4: 60c4 str r4, [r0, adafruit#12] 95e6: 6105 str r5, [r0, adafruit#16] 95e8: 6146 str r6, [r0, adafruit#20] 95ea: 6187 str r7, [r0, adafruit#24] 95ec: 4641 mov r1, r8 95ee: 61c1 str r1, [r0, adafruit#28] 95f0: 4649 mov r1, r9 95f2: 6201 str r1, [r0, adafruit#32] 95f4: 4651 mov r1, sl 95f6: 6241 str r1, [r0, adafruit#36] @ 0x24 95f8: 4659 mov r1, fp 95fa: 6281 str r1, [r0, adafruit#40] @ 0x28 95fc: 4669 mov r1, sp 95fe: 62c1 str r1, [r0, adafruit#44] @ 0x2c 9600: 4671 mov r1, lr 9602: 6081 str r1, [r0, adafruit#8] 9604: e7de b.n 95c4 <nlr_push_tail> [3]: https://www.openwall.com/lists/musl/2020/09/25/4 Signed-off-by: J. Neuschäfer <j.ne@posteo.net>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Right now the feather M0 bluefruit uses the USB PID 0x000b. This is the same as the bootloader PID though and can cause some confusion. Talking to Limor we really want a new PID for this since it's a new 'class' of device with CDC + MSC (vs. just CDC alone that would be PID 0x800b).
The text was updated successfully, but these errors were encountered: