[PATCH v1 1/2] erofs-utils: lib: validate ZSTD frame content size in decompression
Utkal Singh
singhutkal015 at gmail.com
Tue Mar 17 15:47:44 AEDT 2026
Hi Gao Xiang,
Thank you for the review.
Understood, I will include a reproducible way in v2 for both patches.
I have also created a GitHub issue to track these patches:
https://github.com/erofs/erofs-utils/issues/47
v2 will follow shortly.
Best regards,
Utkal Singh
On Tue, 17 Mar 2026 at 07:40, Gao Xiang <hsiangkao at linux.alibaba.com> wrote:
>
>
> On 2026/3/17 05:28, Utkal Singh wrote:
> > ZSTD_getFrameContentSize() reads the content size from the ZSTD
> > frame header in the compressed data. This is untrusted on-disk
> > metadata, independent from the extent map that provides
> > rq->decodedlength via z_erofs_map_blocks_iter().
> >
> > A crafted EROFS image can set the extent map to claim a decoded
> > length larger than the actual ZSTD frame content size. When this
> > happens, a buffer of the (smaller) frame content size is allocated
> > and decompressed into, but the subsequent memcpy copies
> > rq->decodedlength bytes from it — a potential out-of-bounds read.
> >
> > Additionally, the ZSTD_getDecompressedSize() legacy fallback
> > returns 0 for frames without a content size field. This leads to
> > malloc(0) followed by out-of-bounds access on the returned pointer.
> >
> > Reject frames where the reported content size is zero or smaller
> > than the expected decoded length.
>
> For this kind of commits, please add reproduciable way all the time.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/linux-erofs/attachments/20260317/3ea3f34c/attachment.htm>
More information about the Linux-erofs
mailing list