Upgrade MUSL Version

[EricWF]

Hi All,

I'm wondering if there are any plans to upgrade the MUSL libc version? There are a number of printf bugs that have been fixed since 1.1.15.

I tried upgrading it myself but it's non-trivial and there is very little information about the steps needed to do so. I would be willing to try again if I can be provided with a little direction.

[kripken]

I added some docs for how to do that now, see #7286. Let me know if that helps or if anything still isn't clear.

[stale]

This issue has been automatically marked as stale because there has been no activity in the past year. It will be closed automatically if no further activity occurs in the next 7 days. Feel free to re-open at any time if this issue is still relevant.

[sbc100]

We should do this.

[nhooyr]

Please do.

emscripten/system/lib/libc/musl/src/string/strlcpy.c

Line 19 in 46df50c

if (((uintptr_t)s & ALIGN) == ((uintptr_t)d & ALIGN)) {

has caused issues for us as it will read out of bounds when it tries to read 4 bytes at a time. Latest muslc has fixed this: https://git.musl-libc.org/cgit/musl/tree/src/string/strlcpy.c

[kripken]

@nhooyr we updated that file specifically now to fix that issue.

A full update of musl is still very important to do, hopefully someone volunteers to take the time soon!

[kleisauke]

+1 for full update of musl. fwiw, it looks like stpncpy is also affected for the above mentioned bug.

Details

=================================================================
==42==ERROR: AddressSanitizer: global-buffer-overflow on address 0x0226c8e8 at pc 0x009ebc59 bp 0x035abbb0 sp 0x035abbbc
READ of size 4 at 0x0226c8e8 thread T0
    #0 0x9ebc59 in __stpncpy+0x9ebc59 (http://localhost:5000/lib/vips.wasm+0x9ebc59)
    #1 0x9ea6aa in strncpy+0x9ea6aa (http://localhost:5000/lib/vips.wasm+0x9ea6aa)

0x0226c8e8 is located 56 bytes to the left of global variable '<string literal>' defined in 'exif-entry.c:680:27' (0x226c920) of size 10
  '<string literal>' is ascii string 'Top-right'
0x0226c8e9 is located 0 bytes to the right of global variable '<string literal>' defined in 'exif-entry.c:680:11' (0x226c8e0) of size 9
  '<string literal>' is ascii string 'Top-left'
SUMMARY: AddressSanitizer: global-buffer-overflow (http://localhost:5000/lib/vips.wasm+0x9ebc58) in __stpncpy+0x9ebc58
Shadow bytes around the buggy address:
  0x0044d8c0: f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9
  0x0044d8d0: f9 f9 f9 f9 00 06 f9 f9 f9 f9 f9 f9 00 06 f9 f9
  0x0044d8e0: f9 f9 f9 f9 01 f9 f9 f9 f9 f9 f9 f9 00 00 00 03
  0x0044d8f0: f9 f9 f9 f9 00 00 00 03 f9 f9 f9 f9 00 00 00 05
  0x0044d900: f9 f9 f9 f9 00 00 00 05 f9 f9 f9 f9 00 00 01 f9
=>0x0044d910: f9 f9 f9 f9 00 00 00 07 f9 f9 f9 f9 00[01]f9 f9
  0x0044d920: f9 f9 f9 f9 00 02 f9 f9 f9 f9 f9 f9 00 05 f9 f9
  0x0044d930: f9 f9 f9 f9 00 04 f9 f9 f9 f9 f9 f9 00 01 f9 f9
  0x0044d940: f9 f9 f9 f9 00 02 f9 f9 f9 f9 f9 f9 00 05 f9 f9
  0x0044d950: f9 f9 f9 f9 00 04 f9 f9 f9 f9 f9 f9 00 01 f9 f9
  0x0044d960: f9 f9 f9 f9 00 01 f9 f9 f9 f9 f9 f9 00 06 f9 f9
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
  Shadow gap:              cc
==42==ABORTING

(memccpy, memchr, memmove, stpcpy, strchrnul and strlen are probably also affected. See this commit)