it is a memory leaks issue in Mat_VarCalloc (mat.c:807)

[gutiniao]

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

Poc 006-memleak

The ASAN information is as follows:

./matdump /usr/local/matio_asan/bin/006-memleak 
InflateRankDims: inflate returned data error
InflateVarTag: inflate returned data error
Empty
InflateRankDims: Reading dimensions expected type MAT_T_INT32
InflateRankDims: Reading dimensions expected type MAT_T_INT32
      Name:  
      Rank: 0
InflateRankDims: inflate returned data error
131074 is not a valid rank
      Rank: 0
421105169 is not valid (MAT_T_MATRIX or MAT_T_COMPRESSED)

=================================================================
==23803==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 80 byte(s) in 1 object(s) allocated from:
    #0 0x7fbf2001f602 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x98602)
    #1 0x7fbf1fd691df in Mat_VarCalloc /home/matio/matio_src/matio/src/mat.c:807
    #2 0x7fbf1fc9d7bb in ReadNextCell /home/matio/matio_src/matio/src/mat5.c:925
    #3 0x7fbf1fd5d494 in Mat_VarReadNextInfo5 /home/matio/matio_src/matio/src/mat5.c:4998
    #4 0x7fbf1fd73a87 in Mat_VarReadNextInfo /home/matio/matio_src/matio/src/mat.c:2342
    #5 0x408136 in main /home/matio/matio_src/matio/tools/matdump.c:944
    #6 0x7fbf1f54e82f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)

Indirect leak of 32768 byte(s) in 1 object(s) allocated from:
    #0 0x7fbf2001f602 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x98602)
    #1 0x7fbf1ece87d1 in inflateCopy (/usr/local/lib/libz.so.1+0xd7d1)

Indirect leak of 7160 byte(s) in 1 object(s) allocated from:
    #0 0x7fbf2001f602 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x98602)
    #1 0x7fbf1ece87a1 in inflateCopy (/usr/local/lib/libz.so.1+0xd7a1)

Indirect leak of 112 byte(s) in 1 object(s) allocated from:
    #0 0x7fbf2001f79a in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x9879a)
    #1 0x7fbf1fc9efd1 in ReadNextCell /home/matio/matio_src/matio/src/mat5.c:1065
    #2 0x7fbf1fd5d494 in Mat_VarReadNextInfo5 /home/matio/matio_src/matio/src/mat5.c:4998
    #3 0x7fbf1fd73a87 in Mat_VarReadNextInfo /home/matio/matio_src/matio/src/mat.c:2342
    #4 0x408136 in main /home/matio/matio_src/matio/tools/matdump.c:944
    #5 0x7fbf1f54e82f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)

Indirect leak of 40 byte(s) in 1 object(s) allocated from:
    #0 0x7fbf2001f602 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x98602)
    #1 0x7fbf1fd69505 in Mat_VarCalloc /home/matio/matio_src/matio/src/mat.c:823
    #2 0x7fbf1fc9d7bb in ReadNextCell /home/matio/matio_src/matio/src/mat5.c:925
    #3 0x7fbf1fd5d494 in Mat_VarReadNextInfo5 /home/matio/matio_src/matio/src/mat5.c:4998
    #4 0x7fbf1fd73a87 in Mat_VarReadNextInfo /home/matio/matio_src/matio/src/mat.c:2342
    #5 0x408136 in main /home/matio/matio_src/matio/tools/matdump.c:944
    #6 0x7fbf1f54e82f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)

Indirect leak of 9 byte(s) in 1 object(s) allocated from:
    #0 0x7fbf2001f602 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x98602)
    #1 0x7fbf1fc9eb59 in ReadNextCell /home/matio/matio_src/matio/src/mat5.c:1046
    #2 0x7fbf1fd5d494 in Mat_VarReadNextInfo5 /home/matio/matio_src/matio/src/mat5.c:4998
    #3 0x7fbf1fd73a87 in Mat_VarReadNextInfo /home/matio/matio_src/matio/src/mat.c:2342
    #4 0x408136 in main /home/matio/matio_src/matio/tools/matdump.c:944
    #5 0x7fbf1f54e82f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)

SUMMARY: AddressSanitizer: 40169 byte(s) leaked in 6 allocation(s).

[tbeu]

Can you confirm that a47b7cd3aca70e9a0bddf8146eb4ab0cbd19c2c3 fixes the issue? Thanks.

[tbeu]

Closing after no more feedback from issue author.

[carnil]

CVE-2019-20052 was assigned for this issue though.

[tbeu]

Why? This issue never was apparent in a released version.

[carnil]

@tbeu I do not know actually (Note, I'm only the messenger here. I'm part of the Debian security team, and while reviewing new CVE assignments, I cross-checking the upstream issue associated and where needed mention the respective CVE id which got assigned).

In this case I do not know if the CVE is valid or not, but if you think it is not, might you ask as upstream via the https://cveform.mitre.org to reject the CVE? There is no information who requested the CVE, so I unfortunately cannot redirect you to the right person here.

[lewyssmith]

According to our (Mageia) testing, the patch did NOT fix the issue: https://bugs.mageia.org/show_bug.cgi?id=27969#c4 This bug should either be be re-opened, or a new one raised: https://bugs.mageia.org/show_bug.cgi?id=29164

[limburgher]

Is there a corrected patch that isn't reflected in 1.5.18+?

[tbeu]

Hm, I am lost here. I asked for confirmation if a47b7cd3aca70e9a0bddf8146eb4ab0cbd19c2c3 fixes the issue 19 months ago. How does it come that you report now that the issue is not fixed? Why does it take such a long response?

For now, I would prefer if you can file a new pull request (targeting master) to fix whatever needs to be fixed.

[lewyssmith]

"I asked for confirmation if a47b7cd fixes the issue 19 months ago. How does it come that you report now that the issue is not fixed? Why does it take such a long response?"

Our (Mageia) security updates/testing is driven by issued CVE Advisories. I see that this one goes back to at least Dec 2019; it was notified to Mageia Dec 2020, 'fixed' and tested at the turn of the year; then fell into limbo: https://bugs.mageia.org/show_bug.cgi?id=27969#c5

"I would prefer if you can file a new pull request (targeting master) to fix whatever needs to be fixed."

I have raised a new 'bug' as you wish (https://github.com/tbeu/matio/issues/175), but your terminology means nothing to me. It can do little more than reiterate the end of this one.