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 hsiangkao@linux.alibaba.com 于2024年6月5日周三 05:10写道：
On 2024/6/5 06:53, jianqiang wang wrote:
Hi Das U-Boot developers,
...
- 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