Vulnerability Report - 5 findings in erofs-utils

Heap Overflow via u64-to-u32 Truncation in Fragment Decompression
===================================================================
CVSS 3.1: 7.8 (AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H)
CWE: CWE-190 (Integer Overflow)
Target: erofs-utils 1.8.5 (verified unfixed at HEAD, commit 8cd872d)

In erofs_verify_inode_data(), buffer_size is declared as unsigned int
(32-bit) but assigned from map.m_llen which is u64. The truncation
causes an undersized allocation; the subsequent read uses the full
64-bit length, overflowing the buffer.

Vulnerable code (fsck/main.c):

  unsigned int raw_size = 0, buffer_size = 0;  // line 526: u32

  if (map.m_llen > buffer_size) {     // line 593: comparison promotes
                                      // buffer_size to u64, passes
      buffer_size = map.m_llen;       // line 596: TRUNCATION u64->u32
      newbuffer = realloc(buffer, buffer_size);  // undersized alloc
  }

  ret = z_erofs_read_one_data(inode, &map, raw, buffer,
                              0, map.m_llen, false);  // writes full u64

Source type (include/erofs/internal.h:378):

  struct erofs_map_blocks {
      u64 m_plen, m_llen;   // 64-bit
  };

Overflow arithmetic:
  m_llen = 0x100000001 (4GB + 1)
  buffer_size = (uint32_t)0x100000001 = 0x1
  realloc(buffer, 1) -> z_erofs_read_one_data writes ~4GB

Impact: heap overflow with attacker-controlled size (up to ~4GB per
extent) and attacker-controlled content from the EROFS image data
blocks. fsck.erofs runs in Android build pipelines, initramfs
validation, and system image verification, often as root.

Fix: change buffer_size from unsigned int to u64:
  -  unsigned int raw_size = 0, buffer_size = 0;
  +  u64 raw_size = 0, buffer_size = 0;

Off-by-One Heap Overflow in fsck.erofs Path Construction
==========================================================
CVSS 3.1: 6.2 (AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H)
CWE: CWE-193 (Off-by-one Error)
Target: erofs-utils 1.9.1 (verified unfixed at HEAD, commit d3fbccb)

In erofsfsck_dirent_iter(), the bounds check for path construction
does not account for the prepended '/' separator, allowing a null
byte to be written one byte past the PATH_MAX-sized heap buffer.

Vulnerable code (fsck/main.c:901-915):

  if (prev_pos + ctx->de_namelen >= PATH_MAX) {  // line 904
      return -EOPNOTSUPP;                        // check misses '/'
  }

  fsckcfg.extract_path[curr_pos++] = '/';         // line 911: +1
  strncpy(fsckcfg.extract_path + curr_pos,
          ctx->dname, ctx->de_namelen);            // line 912-913
  curr_pos += ctx->de_namelen;                     // line 914
  fsckcfg.extract_path[curr_pos] = '\0';           // line 915: OOB

Buffer: malloc(PATH_MAX) -> valid indices 0 to 4095.

Concrete example (PATH_MAX = 4096):
  prev_pos = 4090, de_namelen = 5
  Check: 4090 + 5 = 4095 < 4096 -> PASSES
  '/' at index 4090, name at 4091-4095, '\0' at 4096 -> OOB

The check allows prev_pos + de_namelen up to PATH_MAX - 1, but
the actual write extends to prev_pos + 1 + de_namelen due to '/'.
Maximum OOB index: PATH_MAX (one byte past allocation).

Impact: single null byte written past a heap buffer (null byte
poisoning). On glibc, this corrupts the size metadata of the
adjacent heap chunk -- a known exploitation primitive (House of
Einherjar) that enables overlapping allocations. At minimum,
heap corruption leads to a crash.

Fix: account for the separator in the bounds check:
  -  if (prev_pos + ctx->de_namelen >= PATH_MAX) {
  +  if (prev_pos + ctx->de_namelen + 1 >= PATH_MAX) {

Heap OOB Read in ZSTD Decompression via Frame Size Mismatch
==============================================================
CVSS 3.1: 5.5 (AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N)
CWE: CWE-125 (Out-of-bounds Read)
Target: erofs-utils (commit 8a579d4, verified at HEAD)

z_erofs_decompress_zstd() allocates a decompression buffer based
on ZSTD_getFrameContentSize() (from the compressed frame header),
but copies rq->decodedlength bytes (from the filesystem extent
metadata) to the output. Both values are independently attacker-
controlled in a crafted EROFS image.

Vulnerable code (lib/decompress.c:52-76):

  total = ZSTD_getFrameContentSize(src + inputmargin, ...);
  // total = from ZSTD frame header (attacker-controlled)

  buff = malloc(total);  // allocates based on frame header

  ret = ZSTD_decompress(dest, total, ...);  // fills 'total' bytes

  memcpy(rq->out, dest + rq->decodedskip,
         rq->decodedlength - rq->decodedskip);
  // copies decodedlength bytes from total-sized buffer

Overflow arithmetic:
  Frame_Content_Size = 100 (ZSTD header)
  m_llen = 12MB (extent metadata, up to Z_EROFS_PCLUSTER_MAX_DSIZE)
  malloc(100) -> memcpy reads 12MB from 100-byte buffer -> ~12MB OOB

Sibling comparison: all other decompression backends (LZ4, LZMA,
DEFLATE, QPL) allocate based on rq->decodedlength, not the
compressed frame's self-declared size. Only ZSTD is vulnerable.

Impact: ~12MB heap OOB read. In erofsfuse, leaked heap data is
returned via FUSE to the reading process. In fsck.erofs --extract,
leaked data is written to extracted files.

Fix: allocate the intermediate buffer based on rq->decodedlength
(consistent with all other backends), or validate that
ZSTD_getFrameContentSize() >= rq->decodedlength.

Integer Overflow in Symlink Extraction Leading to Heap Overflow
=================================================================
CVSS 3.1: 7.8 (AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H)
CWE: CWE-190 (Integer Overflow)
Target: erofs-utils 1.9.1 (verified unfixed at HEAD, commit d3fbccb)

erofs_extract_symlink() allocates a buffer using malloc(i_size + 1)
where i_size is a 64-bit value read directly from the on-disk inode
with no upper bound validation. When i_size equals UINT64_MAX, the
addition wraps to zero, and malloc(0) returns a minimal allocation.
The subsequent erofs_pread() writes i_size bytes into this tiny
buffer.

Vulnerable code (fsck/main.c:797-807):

  buf = malloc(inode->i_size + 1);        // wraps to 0 at UINT64_MAX
  if (!buf) { ret = -ENOMEM; goto out; }  // malloc(0) returns non-NULL

  ret = erofs_pread(&vf, buf, inode->i_size, 0);  // writes i_size bytes

Source of i_size (lib/namei.c:100):

  vi->i_size = le64_to_cpu(die->i_size);  // raw 64-bit, no validation

Overflow arithmetic:
  i_size = 0xFFFFFFFFFFFFFFFF
  malloc(0xFFFFFFFFFFFFFFFF + 1) = malloc(0) -> ~16-32 byte allocation
  erofs_pread writes 0xFFFFFFFFFFFFFFFF bytes into 16-32 byte buffer

On 32-bit platforms, compact inodes (32-bit i_size = 0xFFFFFFFF)
also trigger the same pattern when size_t is 32 bits.

Impact: heap overflow with attacker-controlled write size and
attacker-controlled content (from EROFS image data blocks). This
provides a write-what-where primitive on the heap.

Fix: validate i_size before allocation:
  if (inode->i_size > PATH_MAX || inode->i_size > SIZE_MAX - 1) {
      erofs_err("symlink too large");
      return -EFSCORRUPTED;
  }
  buf = malloc(inode->i_size + 1);

Uncontrolled Recursion in dump.erofs Directory Traversal
==========================================================
CVSS 3.1: 5.5 (AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H)
CWE: CWE-674 (Uncontrolled Recursion)
Target: erofs-utils 1.9.1 (verified unfixed at HEAD, commit d3fbccb)

erofsdump_readdir() in dump.erofs recursively traverses directories
without depth limiting or cycle detection. A crafted EROFS image
with circular directory references causes unbounded recursion,
exhausting the process stack.

The developer acknowledged this with a comment at line 362:
  /* XXXX: the dir depth should be restricted in order to avoid loops */

Vulnerable code (dump/main.c:362-371):

  /* XXXX: the dir depth should be restricted ... */
  if (S_ISDIR(vi.i_mode)) {
      struct erofs_dir_context nctx = {
          .flags = ctx->dir ? EROFS_READDIR_VALID_PNID : 0,
          .pnid = ctx->dir ? ctx->dir->nid : 0,
          .dir = &vi,
          .cb = erofsdump_dirent_iter,
      };
      return erofs_iterate_dir(&nctx, false);  // no guard
  }

Sibling comparison -- fsck.erofs has both protections (fsck/main.c):

  if (fsckcfg.dirstack.top >= ARRAY_SIZE(fsckcfg.dirstack.dirs))
      return -ENAMETOOLONG;                    // depth limit
  for (i = 0; i < fsckcfg.dirstack.top; ++i)
      if (inode.nid == fsckcfg.dirstack.dirs[i])
          return -ELOOP;                       // cycle detection

Trigger: directory A contains entry pointing to directory B, B points
back to A. Each recursive call allocates struct erofs_inode + context
+ block buffer on the stack. Stack exhaustion produces SIGSEGV.

Impact: deterministic crash (denial of service) from crafted image.

Fix: add depth limiting and cycle detection matching the existing
fsck.erofs implementation, or convert to iterative traversal with
an explicit stack.