Several potential vulnerabilities in the filesystem
Gao Xiang
hsiangkao at linux.alibaba.com
Wed Jun 5 13:18:14 CEST 2024
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
>>
More information about the U-Boot
mailing list