Re: Several potential vulnerabilities in the filesystem

[Gao Xiang]

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