Several potential vulnerabilities in the filesystem

[Jianan Huang]

On 2024/6/5 19:18, Gao Xiang wrote:
> 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?

https://lore.kernel.org/u-boot/20240605140554.1883-1-jnhuang95@gmail.com/T/#u

Thanks,
Jianan

>
> 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
>>>