Hi Gao Xiang,

Thank you for reviewing the reports. Attached are demo images for the 3
findings that crash cleanly under AddressSanitizer (erofs-pocs.tar.gz,
~1KB). Findings 2 and 4 are straightforward from the source and noted
below.

(I stripped their .img extension to prevent Gmail disallowing to attach)

Build ASAN binaries first:

  cd erofs-utils-1.8.5
  CFLAGS="-fsanitize=address -g -O1" LDFLAGS="-fsanitize=address" \
    ./configure --with-zstd --with-lz4 --with-zlib && make

  cd erofs-utils-1.9.1
  CFLAGS="-fsanitize=address -g -O1" LDFLAGS="-fsanitize=address" \
    ./configure --with-zstd --with-lz4 --with-zlib && make

---

1. ZSTD decompression heap OOB read (CWE-125, affects 1.8.5):

  mkdir -p /tmp/out1
  fsck.erofs --extract=/tmp/out1 poc1-zstd-oob.erofs.img

  ASAN reports: heap-buffer-overflow READ of size 8192 at decompress.c:71
  (memcpy from 100-byte buffer allocated at decompress.c:50)

  The image contains a ZSTD-compressed file where the ZSTD frame header
  declares Frame_Content_Size=100, but the extent metadata claims
  decodedlength=8192. malloc(100) is called, ZSTD decompresses 100 bytes,
  then memcpy reads 8192 bytes from the 100-byte buffer.

---

2. u64-to-u32 truncation heap overflow (CWE-190, affects 1.8.5):

  The type mismatch is at fsck/main.c:526: "unsigned int buffer_size"
  assigned from "map.m_llen" (u64). Any compressed extent with
  m_llen > 2^32 truncates the allocation size while the full u64 length
  flows into z_erofs_read_one_data() and write(). Visible directly in
  the source.

---

3. Off-by-one heap overflow in fsck path construction (CWE-193, affects
1.9.1):

  mkdir -p /tmp/e
  fsck.erofs --extract=/tmp/e poc3-obo-pathmax.erofs.img

  ASAN reports: heap-buffer-overflow WRITE of 1 byte at fsck/main.c:915
  (erofsfsck_dirent_iter)

  The image contains 17 directories nested to reach exactly PATH_MAX-1
  (4095) characters of accumulated path. The extraction prefix "/tmp/e"
  (6 chars) plus 15 levels of 255-char names plus one 249-char name
  totals 4095. The check at fsck/main.c compares prev_pos + namelen
  against PATH_MAX, which passes (4095 < 4096), but the null terminator
  write goes to buf[4096], one byte past the allocated buffer.

  IMPORTANT: the extract path must be exactly 6 characters ("/tmp/e")
  for the boundary to align.

---

4. Symlink i_size integer overflow (CWE-190, affects 1.9.1):

  The vulnerable code at fsck/main.c:797 computes malloc(i_size + 1)
  which wraps to malloc(0) when i_size is 0xFFFFFFFFFFFFFFFF.
  erofs_map_blocks() currently rejects such inodes before reaching the
  vulnerable path (BLK_ROUND_UP overflows to 0), but this is an
  incidental block, not a sanitization check -- the malloc overflow
  itself is unfixed.

---

5. Uncontrolled recursion in dump.erofs (CWE-674, affects 1.9.1):

  dump.erofs -S poc5-recursion.erofs.img

  ASAN reports: stack-overflow (SEGV on address near the stack limit)

  The image contains a root directory with a "loop" entry whose nid
  points back to the root (nid=0). dump.erofs -S traverses the directory
  tree recursively without cycle detection, causing unbounded stack growth.

---

Let me know if you need anything else.

Regards,
Tristan



Le jeu. 11 juin 2026 à 03:40, Gao Xiang <[email protected]> a
écrit :

> Hi,
>
> On 2026/6/11 05:27, Tristan wrote:
> > Hello,
> >
> > I am reporting 5 vulnerabilities in erofs-utils across three versions.
> > All are triggered by crafted EROFS filesystem images.
> >
> > Findings summary:
> >
> >    - ZSTD decompression heap OOB read (erofs-utils 8a579d4, CVSS 5.5,
> > CWE-125)
> >    - u64-to-u32 truncation heap overflow (erofs-utils 1.8.5, CVSS 7.8,
> > CWE-190)
> >    - Off-by-one heap overflow in fsck path (erofs-utils 1.9.1, CVSS 6.2,
> > CWE-193)
> >    - Symlink extraction integer overflow (erofs-utils 1.9.1, CVSS 7.8,
> > CWE-190)
> >    - Uncontrolled recursion in dump.erofs (erofs-utils 1.9.1, CVSS 5.5,
> > CWE-674)
> >
> > I would appreciate acknowledgement of receipt and CVE assignment.
>
> Although I agree that some issues are obvious issues, but
> would you mind provide reproducible images (in gzipped-based64)
> at least?
>
> Thanks,
> Gao Xiang
>
>
> >
> > Regards,
> > Tristan
> >
>
>

Attachment: erofs-pocs.tar.gz
Description: application/gzip

Reply via email to