Several potential vulnerabilities in the filesystem

[jianqiang wang]

Could you please forward the issues to whoever is responsible for them?

Gao Xiang <hsiangkao at linux.alibaba.com> 于2024年6月5日周三 13:35写道：
>
>
>
> On 2024/6/5 19:26, jianqiang wang wrote:
> > Hi Xiang,
> >
> > I just checked the second crash, the patch can solve this issue. Did
> > you also look into the other two issues?
>
> I'm only responsible for the EROFS project.
>
> Thanks,
> Gao Xiang
>
> >
> > Best
> > Jianqiang
> >
> > Gao Xiang <hsiangkao at linux.alibaba.com> 于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 <hsiangkao at linux.alibaba.com> 于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
> >>>>