<div dir="ltr">Hi Gao,<br><br>Thanks for the detailed explanation. I understand now that erofs_io_read()<br>already handles the out-of-bounds case and returns an appropriate error,<br>so the additional check against primarydevice_blocks is unnecessary.<br><br>I also wasn't aware that primarydevice_blocks can legitimately be 0<br>for dynamically generated EROFS images, so my change would indeed<br>break valid use cases.<br><br>Thanks again for reviewing and clarifying this. I’ll keep this in<br>mind for future patches.<br><br>Best regards,<br>Utkal Singh</div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Thu, 5 Mar 2026 at 05:29, 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/5 07:45, Gao Xiang wrote:<br>
> <br>
> <br>
> On 2026/3/5 02:21, Utkal Singh wrote:<br>
>> A crafted EROFS image can contain an out-of-range node ID in directory<br>
>> entries or the superblock root_nid that causes erofs_iloc() to compute<br>
>> an inode offset beyond the image size. This leads to out-of-bounds<br>
>> reads in erofs_read_metabuf(), potentially crashing fsck.erofs,<br>
>> erofsfuse, or dump.erofs.<br>
> <br>
> Do you have a reproducible image?<br>
> <br>
> I think in that way, erofs_io_read or something should fail<br>
> instead, we don't need such check against<br>
> sbi->primarydevice_blocks.<br>
<br>
It will return:<br>
<E> erofs: erofs_read_inode_from_disk() Line[42] failed to get inode (nid: 249216) page, err -5<br>
<E> erofs: erofsfsck_check_inode() Line[988] I/O error occurred when reading nid(249216)<br>
<br>
I don't think such check is needed, blocks is mainly for statfs<br>
statistics, for dynamic generated EROFS, it could be 0 all the<br>
time.<br>
</blockquote></div>