There is a stack-based buffer overflow in the Mat_VarReadNextInfo5 function of mat5.c(at 4915)

[gutiniao]

A crafted input will lead to crash in mat5.c at matio 1.5.17. Triggered by ./matdump POC

Poc 001-stackover-Mat_VarReadNextInfo5_mat54915

The ASAN information is as follows:

./matdump 001-stackover-Mat_VarReadNextInfo5_mat54915 
InflateRankDims: inflate returned data error
=================================================================
==31427==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffcc32c92d0 at pc 0x7fcd463809a6 bp 0x7ffcc32c90c0 sp 0x7ffcc32c90b0
READ of size 4 at 0x7ffcc32c92d0 thread T0
    #0 0x7fcd463809a5 in Mat_VarReadNextInfo5 /home/matio_asan/src/mat5.c:4915
    #1 0x7fcd4639746b in Mat_VarReadNextInfo /home/matio_asan/src/mat.c:2342
    #2 0x408126 in main /home/matio_asan/tools/matdump.c:944
    #3 0x7fcd45b7282f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
    #4 0x401b58 in _start (/usr/local/matio_asan/bin/matdump+0x401b58)

Address 0x7ffcc32c92d0 is located in stack of thread T0 at offset 416 in frame
    #0 0x7fcd4637fc54 in Mat_VarReadNextInfo5 /home/matio_asan/src/mat5.c:4788

  This frame has 6 object(s):
    [32, 36) 'data_type'
    [96, 100) 'nBytes'
    [160, 168) 'dims'
    [224, 232) 'size'
    [288, 312) 'buf'
    [352, 416) 'uncomp_buf' <== Memory access at offset 416 overflows 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 /home/matio_asan/src/mat5.c:4915 Mat_VarReadNextInfo5
Shadow bytes around the buggy address:
  0x100018651200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100018651210: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100018651220: 00 00 00 00 00 00 f1 f1 f1 f1 04 f4 f4 f4 f2 f2
  0x100018651230: f2 f2 04 f4 f4 f4 f2 f2 f2 f2 00 f4 f4 f4 f2 f2
  0x100018651240: f2 f2 00 f4 f4 f4 f2 f2 f2 f2 00 00 00 f4 f2 f2
=>0x100018651250: f2 f2 00 00 00 00 00 00 00 00[f3]f3 f3 f3 f3 f3
  0x100018651260: f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100018651270: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 f4 f4 f4
  0x100018651280: f2 f2 f2 f2 00 04 f4 f4 f3 f3 f3 f3 00 00 00 00
  0x100018651290: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1000186512a0: 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
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
==31427==ABORTING

about code (4915):

    if ( mat->byteswap ) {
                        for ( j = 0; j < matvar->rank; j++ )
                            matvar->dims[j] = Mat_uint32Swap(dims + j);
                    } else {
                        for ( j = 0; j < matvar->rank; j++ )
----------------->   matvar->dims[j] = dims[j];
                    }

[tbeu]

No need to report fuzzing issues since matio is on OSS-Fuzz with still about 40 open issues.

Instead of v1.5.17, please rerun the test against current master and reopen if the issue is still reproducible.

[gutiniao]

No need to report fuzzing issues since matio is on OSS-Fuzz with still about 40 open issues.

Instead of v1.5.17, please rerun the test against current master and reopen if the issue is still reproducible.

Yes, I just use 'git clone' to fetch the current master of the matio,the issue is still reproducible.

i 'm sure the issue is different from the fuzzing issues on OSS-fuzz.

[tbeu]

I cannot reproduce.

[gutiniao]

I cannot reproduce.

Your fixs about issue 128 and issue 129 have solve the problem . but there is a new issue

[carnil]

CVE-2019-20017 has been assigned for this issue.