Project: matio (tbeu/matio), language: c++
Vulnerability instance: matio.cve-2019-20052
Sanitizer: address

================= Bug Report (1/1) ==================
## Source: GitHub Issue
## URL: https://github.com/tbeu/matio/issues/131
## Description:
Issue: tbeu/matio#131
Title: it is a memory leaks issue in Mat_VarCalloc (mat.c:807)
State: closed
Created by: gutiniao
Created at: 2019-11-12 05:36:29+00:00

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

Poc
[006-memleak](https://github.com/gutiniao/afltest/blob/master/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).
```




Comments:
Comment by tbeu on 2019-11-23 21:17:22+00:00:
Can you confirm that a47b7cd3aca70e9a0bddf8146eb4ab0cbd19c2c3 fixes the issue? Thanks.

---

Comment by tbeu on 2019-12-27 13:53:13+00:00:
Closing after no more feedback from issue  author.

---

Comment by carnil on 2019-12-28 08:19:57+00:00:
CVE-2019-20052 was assigned for this issue though.

---

Comment by tbeu on 2019-12-28 08:21:54+00:00:
Why? This issue never was apparent in a released version.

---

Comment by carnil on 2019-12-28 20:18:20+00:00:
@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.

---

Comment by lewyssmith on 2021-06-22 07:34:05+00:00:
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

---

Comment by limburgher on 2021-06-23 16:19:54+00:00:
Is there a corrected patch that isn't reflected in 1.5.18+?

---

Comment by tbeu on 2021-06-24 13:33:00+00:00:
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.

---

Comment by lewyssmith on 2021-06-25 12:30:04+00:00:
> "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.

Commit References:
a47b7cd3aca70e9a0bddf8146eb4ab0cbd19c2c3

Build script:
#!/bin/bash -eu
# Minimized build script with only core build commands
set -eu
./autogen.sh
./configure
make -j$(nproc)
make install -j$(nproc)

Dockerfile:
FROM hwiwonlee/secb.base:latest
RUN apt-get update && apt-get install -y make autoconf automake libtool
RUN git clone https://github.com/tbeu/matio matio
RUN git -C matio checkout 64f793668e09216029447990702c145403d14375
WORKDIR $SRC/matio
COPY build.sh $SRC/

Additional files:
filename: fuzzer_temp_file.h
content: // Copyright 2019 Google Inc.
//
// Licensed under the Apache License, Version 2.0 (the "License");
// you may not use this file except in compliance with the License.
// You may obtain a copy of the License at
//
//      http://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing, software
// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.

// Adapter utility from fuzzer input to a temporary file, for fuzzing APIs that
// require a file instead of an input buffer.

#ifndef FUZZER_TEMP_FILE_H_
#define FUZZER_TEMP_FILE_H_

#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>

// Pure-C interface for creating and cleaning up temporary files.

static char* fuzzer_get_tmpfile(const uint8_t* data, size_t size) {
  char* filename_buffer = strdup("/tmp/generate_temporary_file.XXXXXX");
  if (!filename_buffer) {
    perror("Failed to allocate file name buffer.");
    abort();
  }
  const int file_descriptor = mkstemp(filename_buffer);
  if (file_descriptor < 0) {
    perror("Failed to make temporary file.");
    abort();
  }
  FILE* file = fdopen(file_descriptor, "wb");
  if (!file) {
    perror("Failed to open file descriptor.");
    close(file_descriptor);
    abort();
  }
  const size_t bytes_written = fwrite(data, sizeof(uint8_t), size, file);
  if (bytes_written < size) {
    close(file_descriptor);
    fprintf(stderr, "Failed to write all bytes to file (%zu out of %zu)",
            bytes_written, size);
    abort();
  }
  fclose(file);
  return filename_buffer;
}

static void fuzzer_release_tmpfile(char* filename) {
  if (unlink(filename) != 0) {
    perror("WARNING: Failed to delete temporary file.");
  }
  free(filename);
}

// C++ RAII object for creating temporary files.

#ifdef __cplusplus
class FuzzerTemporaryFile {
 public:
  FuzzerTemporaryFile(const uint8_t* data, size_t size)
      : filename_(fuzzer_get_tmpfile(data, size)) {}

  ~FuzzerTemporaryFile() { fuzzer_release_tmpfile(filename_); }

  const char* filename() const { return filename_; }

 private:
  char* filename_;
};
#endif

#endif  // FUZZER_TEMP_FILE_H_

filename: matio_fuzzer.cc
content: // Copyright 2019 Google Inc.
//
// Licensed under the Apache License, Version 2.0 (the "License");
// you may not use this file except in compliance with the License.
// You may obtain a copy of the License at
//
//      http://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing, software
// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.

// Adapter utility from fuzzer input to a temporary file, for fuzzing APIs that
// require a file instead of an input buffer.

#include <cstddef>
#include <cstdint>
#include <cstdlib>
#include <string>
#include <vector>

#include "fuzzer_temp_file.h"
#include "matio.h"

extern "C" int LLVMFuzzerTestOneInput(const uint8_t* data, size_t size) {
  FuzzerTemporaryFile temp_file(data, size);

  mat_t* matfd = Mat_Open(temp_file.filename(), MAT_ACC_RDONLY);
  if (matfd == nullptr) {
    return 0;
  }
  // TODO(https://github.com/google/oss-fuzz/pull/2761): use more complicated APIs
  // such as Mat_VarReadDataAll, Mat_VarReadDataLinear, Mat_VarReadNext, etc. 
  Mat_Close(matfd);

  return 0;
}