<div dir="ltr">Hi Gao Xiang,<br><br>Thank you for the review.<br><br>Understood, I will include a reproducible way in v2 for both patches.<br><br>I have also created a GitHub issue to track these patches:<br><a href="https://github.com/erofs/erofs-utils/issues/47">https://github.com/erofs/erofs-utils/issues/47</a><br><br>v2 will follow shortly.<br><br>Best regards,<br>Utkal Singh<div><br></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Tue, 17 Mar 2026 at 07:40, Gao Xiang <<a href="mailto:hsiangkao@linux.alibaba.com">hsiangkao@linux.alibaba.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
On 2026/3/17 05:28, Utkal Singh wrote:<br>
> ZSTD_getFrameContentSize() reads the content size from the ZSTD<br>
> frame header in the compressed data. This is untrusted on-disk<br>
> metadata, independent from the extent map that provides<br>
> rq->decodedlength via z_erofs_map_blocks_iter().<br>
> <br>
> A crafted EROFS image can set the extent map to claim a decoded<br>
> length larger than the actual ZSTD frame content size. When this<br>
> happens, a buffer of the (smaller) frame content size is allocated<br>
> and decompressed into, but the subsequent memcpy copies<br>
> rq->decodedlength bytes from it — a potential out-of-bounds read.<br>
> <br>
> Additionally, the ZSTD_getDecompressedSize() legacy fallback<br>
> returns 0 for frames without a content size field. This leads to<br>
> malloc(0) followed by out-of-bounds access on the returned pointer.<br>
> <br>
> Reject frames where the reported content size is zero or smaller<br>
> than the expected decoded length.<br>
<br>
For this kind of commits, please add reproduciable way all the time.<br>
</blockquote></div>