[Bug]: test failure because of a global-buffer-overflow

[asarubbo]

Describe the bug

Our Gentoo Tinderbox reported a test failure at bug 914170

By looking at test-suite.log I can see:

==1161==ERROR: AddressSanitizer: global-buffer-overflow on address 0x5614ecd418a0 at pc 0x7f8d20216905 bp 0x7ffd6a482040 sp 0x7ffd6a482038
READ of size 16 at 0x5614ecd418a0 thread T0
    #0 0x7f8d20216904 in crc64_clmul /var/tmp/portage/app-arch/xz-utils-5.4.4/work/xz-5.4.4/src/liblzma/check/crc64_fast.c:284:40
    #1 0x5614ecd2a53c in test_lzma_crc64 /var/tmp/portage/app-arch/xz-utils-5.4.4/work/xz-5.4.4/tests/test_check.c:106:2
    #2 0x5614ecd2a237 in tuktest_run_test /var/tmp/portage/app-arch/xz-utils-5.4.4/work/xz-5.4.4/tests/tuktest.h:596:4
    #3 0x5614ecd29cec in main /var/tmp/portage/app-arch/xz-utils-5.4.4/work/xz-5.4.4/tests/test_check.c:383:2
    #4 0x7f8d1fe23c89  (/lib64/libc.so.6+0x23c89)
    #5 0x7f8d1fe23d44 in __libc_start_main (/lib64/libc.so.6+0x23d44)
    #6 0x5614ecc553f0 in _start (/var/tmp/portage/app-arch/xz-utils-5.4.4/work/xz-5.4.4-abi_x86_64.amd64/tests/.libs/test_check+0x203f0)

0x5614ecd418a0 is located 32 bytes before global variable '.str.42' defined in '/var/tmp/portage/app-arch/xz-utils-5.4.4/work/xz-5.4.4/tests/test_check.c:78' (0x5614ecd418c0) of size 51
  '.str.42' is ascii string 'assert_uint: '%s == %lu' but expected '... %s %lu''
0x5614ecd418a9 is located 0 bytes after global variable 'test_string' defined in '/var/tmp/portage/app-arch/xz-utils-5.4.4/work/xz-5.4.4/tests/test_check.c:22' (0x5614ecd418a0) of size 9
SUMMARY: AddressSanitizer: global-buffer-overflow /var/tmp/portage/app-arch/xz-utils-5.4.4/work/xz-5.4.4/src/liblzma/check/crc64_fast.c:284:40 in crc64_clmul
Shadow bytes around the buggy address:
  0x5614ecd41600: 07 f9 f9 f9 f9 f9 f9 f9 00 00 00 05 f9 f9 f9 f9
  0x5614ecd41680: 00 00 00 03 f9 f9 f9 f9 00 00 00 00 00 00 00 04
  0x5614ecd41700: f9 f9 f9 f9 06 f9 f9 f9 06 f9 f9 f9 07 f9 f9 f9
  0x5614ecd41780: 00 07 f9 f9 00 04 f9 f9 00 02 f9 f9 00 00 00 00
  0x5614ecd41800: 00 06 f9 f9 f9 f9 f9 f9 00 00 00 00 00 02 f9 f9
=>0x5614ecd41880: f9 f9 f9 f9[00]01 f9 f9 00 00 00 00 00 00 03 f9
  0x5614ecd41900: f9 f9 f9 f9 00 00 00 00 00 00 f9 f9 f9 f9 f9 f9
  0x5614ecd41980: 03 f9 f9 f9 00 04 f9 f9 00 00 00 00 00 00 07 f9
  0x5614ecd41a00: f9 f9 f9 f9 04 f9 f9 f9 00 00 00 02 f9 f9 f9 f9
  0x5614ecd41a80: 00 00 00 00 00 00 f9 f9 f9 f9 f9 f9 00 00 00 00
  0x5614ecd41b00: 00 00 07 f9 f9 f9 f9 f9 00 00 00 03 f9 f9 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
==1161==ABORTING

I didn't look deeply into this issue so I don't know if the bug is in the unittest itself or in the involed libraries/daemons, if so please check for any security implications. I'm not doing a private report since it is already public on gentoo bugzilla. If I can do further, please let me know.

Version

5.4.4

Operating System

Gentoo

Relevant log output

No response

[Larhzu]

Thanks!

It's fixed in the master branch now. The problem is that crc64_clmul uses 16-byte-aligned reads and this unavoidably trips the address sanitizer. The CI builds used -fsanitize=address but ci.yml worked around the problem with --disable-clmul-crc. Now there is __attribute__((__no_sanitize_address__)) so the workaround isn't needed anymore.

After 5.4.x (including the current master branch) you will need --disable-ifunc to make -fsanitize=address work. This is because __attribute__((__ifunc(..))) isn't compatible with address sanitizer. See this, search for "asan". The ifunc code likely won't be included in 5.4.x releases.