make check triggers a stack buffer overflow

[mikispag]

When compiled with ASAN (-fsanitize=address), make check gives:

Checking Profile creation .....................=================================================================
==31486==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffdd564bdd8 at pc 0x2aec9c17593d bp 0x7ffdd564b9a0 sp 0x7ffdd564b978
READ of size 392 at 0x7ffdd564bdd8 thread T0
    #0 0x2aec9c17593c in __interceptor_memmove ../../.././libsanitizer/asan/asan_interceptors.cc:358
    #1 0x463b5a in _cmsDupDefaultFn /home/mikispag/Downloads/lcms2-2.7/src/cmserr.c:172
    #2 0x4aee47 in cmsWriteTag /home/mikispag/Downloads/lcms2-2.7/src/cmsio0.c:1686
    #3 0x449f6b in CheckICCViewingConditions /home/mikispag/Downloads/lcms2-2.7/testbed/testcms2.c:4992
    #4 0x449f6b in CheckProfileCreation /home/mikispag/Downloads/lcms2-2.7/testbed/testcms2.c:5319
    #5 0x41f187 in Check /home/mikispag/Downloads/lcms2-2.7/testbed/testcms2.c:310
    #6 0x407322 in main /home/mikispag/Downloads/lcms2-2.7/testbed/testcms2.c:8339
    #7 0x2aec9d55dec4 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21ec4)
    #8 0x408e9c (/home/mikispag/Downloads/lcms2-2.7/testbed/testcms+0x408e9c)

Address 0x7ffdd564bdd8 is located in stack of thread T0 at offset 280 in frame
    #0 0x4452af in CheckProfileCreation /home/mikispag/Downloads/lcms2-2.7/testbed/testcms2.c:5192

  This frame has 6 object(s):
    [32, 39) 'Buffer'
    [96, 112) 'c'
    [160, 184) 'Curves'
    [224, 280) 's'
    [320, 392) 'c' <== Memory access at offset 280 partially underflows this variable
    [448, 704) 'Buffer' <== Memory access at offset 280 partially underflows 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 ../../.././libsanitizer/asan/asan_interceptors.cc:358 __interceptor_memmove
Shadow bytes around the buggy address:
  0x10003aac1760: 00 f4 f2 f2 f2 f2 00 00 00 00 00 00 00 00 00 00
  0x10003aac1770: 00 00 04 f4 f4 f4 f3 f3 f3 f3 00 00 00 00 00 00
  0x10003aac1780: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10003aac1790: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 07 f4 f4 f4
  0x10003aac17a0: f2 f2 f2 f2 00 00 f4 f4 f2 f2 f2 f2 00 00 00 f4
=>0x10003aac17b0: f2 f2 f2 f2 00 00 00 00 00 00 00[f4]f2 f2 f2 f2
  0x10003aac17c0: 00 00 00 00 00 00 00 00 00 f4 f4 f4 f2 f2 f2 f2
  0x10003aac17d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10003aac17e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10003aac17f0: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00
  0x10003aac1800: 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
==31486==ABORTING

[mm2]

Thank you very much, this was a real bug in the code. Fixed in my development sources.

[mikispag]

Amazed by the speed, thanks! It would be cool to run the samples too with ASAN - I see a lot of memory corruption unfortunately.

[pkthapa]

@mm2 Could you please share the commit link for this issue resolution? What was the fix done?

[mm2]

This is from 2015, please update to something more actual, other bugs have been fixed.