memory error in fill_buffer lrzip/stream.c

[Chaitra Niddodi]

requested allocation size 0x900000000000000 (0x900000000001000 after adjustments for alignment, red zones etc.) exceeds maximum supported size of 0x10000000000 (thread T0) in fill_buffer lrzip/stream.c

Built from git commit hash e5e9a61
OS: Ubuntu 20.04
Compiler: clang version 11.0

Build options:

• Shared library disabled
  CC=clang
  CXX=clang++
  CFLAGS="-g -fno-inline -fsanitize=address"
  CXXFLAGS="-g -fno-inline -fsanitize=address"
  LDFLAGS="$LDFLAGS -fsanitize=address"
  ASAN_OPTIONS=abort_on_error=1

Command: ./lrzip -t pov

POV file:
pov.zip

Stack trace:

==1471233==ERROR: AddressSanitizer: requested allocation size 0x900000000000000 (0x900000000001000 after adjustments for alignment, red zones etc.) exceeds maximum supported size of 0x10000000000 (thread T0)
#0 0x4c27af in malloc /home/chaitra/aflgo-top/build/llvm_tools/llvm-11.0.0.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:145:3
#1 0x53d2a9 in fill_buffer lrzip/stream.c:1692:10
#2 0x53b01d in read_stream lrzip/stream.c:1812:8
#3 0x531818 in read_u8 lrzip/runzip.c:55:6
#4 0x53075c in read_header lrzip/runzip.c:144:10
#5 0x52df65 in runzip_chunk lrzip/runzip.c:319:16
#6 0x52b44e in runzip_fd lrzip/runzip.c:387:7
#7 0x50d4f4 in decompress_file lrzip/lrzip.c:876:6
#8 0x4ff407 in main lrzip/main.c:720:4
#9 0x7f24476fc082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16
==1471233==HINT: if you don't care about these errors you may set allocator_may_return_null=1
SUMMARY: AddressSanitizer: allocation-size-too-big /home/chaitra/aflgo-top/build/llvm_tools/llvm-11.0.0.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:145:3 in malloc
==1471233==ABORTING

[Peter Hyman]

snip...

requested allocation size 0x900000000000000 (0x900000000001000 after adjustments for alignment, red zones etc.) exceeds maximum supported size of 0x10000000000 (thread T0) in fill_buffer lrzip/stream.c

If you have an intentionally corrupted file, what would you expect? The fix is to catch the corruption before it is processed. lrzip-next has a validation procedure, but also rejects anything less than an lrzip v0.6 file.

Don't you have anything better to contribute? Why not submit a PR to the project? Quit trying to tear the building down. Help build it up.

$ hexdump -C pov
00000000  4c 52 5a 49 00 04 01 00  00 00 00 00 00 0e 00 00  |LRZI............|
00000010  00 00 00 18 ff f3 00 00  03 00 00 00 00 00 00 00  |................|
00000020  00 00 00 00 00 00 00 00  00 09 00 00 00 00 00 00  |................|
00000030  00 03 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000040  00 00 00 03 00 00 00 0c  de 03 00 00              |............|

and a further review from ps2lrz

$ ps2lrz -i pov
pov is an lrzip version 0.4 file
pov is not encrypted
pov uncompressed file size is 1,008,806,316,530,991,105 bytes
Dumping magic header 24 bytes
Byte Offset      Description/Content
===========      ===================
Magic Bytes 0-3: 4C 52 5A 49 LRZI
Bytes 4-5:       LRZIP Major, Minor version: 00, 04
Bytes 6-13:      LRZIP Uncompressed Size bytes: 01 00 00 00 00 00 00 0E 
Bytes 14 and 15: unused
Bytes 16-20:     unused. Not an LZMA compressed archive
Byte  21:        Hash Sum at EOF: (null)
Byte  22:        File is encrypted: NONE