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.
Best regards
Gao Xiang <hsiang...@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
>
payload_00763
Description: Binary data
payload_00846
Description: Binary data
payload_00500
Description: Binary data
