Hi Xiang, I just checked the second crash, the patch can solve this issue. Did you also look into the other two issues?
Best Jianqiang Gao Xiang <[email protected]> 于2024年6月5日周三 13:18写道： > > Hi Jianqiang, > > On 2024/6/5 19:00, jianqiang wang wrote: > > Hi, > > > > I do have the crafted image. > > > > payload_00500, payload_00763, payload_00846 can be used to reproduce > > 1,2,3 vulnerabilities respectively. > > > > Each image is a hard drive file and the vulnerabilities can be > > triggered by performing the following operations: > > > > struct udevice *dev; > > uclass_first_device_err(UCLASS_IDE, &dev); //detect the block device > > > > fs_set_blk_dev("ide","0:1", 0); > > fs_ls("/"); //mount the first partition and list the root directory > > files > > > > fs_set_blk_dev("ide","0:1", 0); > > char buf[10]; > > buf[0] = 0; > > buf[1] = 0; > > buf[2] = 0; > > buf[3] = 0; > > loff_t actread = 0; > > fs_read("/a.txt", (ulong)buf, 0, 5, &actread); > > printf("fd actread %lld %x %x %x\n",actread,buf[0],buf[1],buf[2]); > > read the /a.txt file > > > > > > fs_set_blk_dev("ide","0:1", 0); > > fs_read("/a.txt.ln", (ulong)buf, 0, 5, &actread); > > printf("fd actread %lld %x %x %x\n",actread,buf[0],buf[1],buf[2]); > > read the /a.txt.ln symbol file > > > > fs_set_blk_dev("ide","0:1", 0); > > fs_unlink("/a.txt.ln"); //unlink it > > > > The second and third may not trigger a crash however, can be observed > > by inserting logging before the memset/memcpy function. > > Sorry, I just found that this issue was already fixed in erofs-utils: > https://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs-utils.git/commit/?id=884866ca07817e97c59605a2fa858a0b732d3f3c > > Would you mind checking if the patch above fixes the issue? > > Hi Jianan, > Would you mind backporting this patch for u-boot? > > Thanks, > Gao Xiang > > > > > Best regards > > > > Gao Xiang <[email protected]> 于2024年6月5日周三 05:10写道： > >> > >> > >> > >> On 2024/6/5 06:53, jianqiang wang wrote: > >>> Hi Das U-Boot developers, > >>> > >> > >> ... > >> > >>> > >>> 2. in file fs/erofs/data.c, function z_erofs_read_one_data, the node > >>> data is read from the storage, however, without a proper check, the > >>> data can be corrupted. For example, the inode data is used in function > >>> z_erofs_read_data, map.m_llen will be calculated to a very large > >>> value, which means the length variable will be very large. It will > >>> cause a large memory clear with memset(buffer + end - offset, 0, > >>> length); > >> > >> Would you mind giving a reproducer or a crafted image to trigger > >> this? Or it's your pure observation. > >> > >> Thanks, > >> Gao XIang > >>
