On 2024/6/5 19:26, jianqiang wang wrote:
Hi Xiang,

I just checked the second crash, the patch can solve this issue. Did
you also look into the other two issues?

I'm only responsible for the EROFS project.

Thanks,
Gao Xiang


Best
Jianqiang

Gao Xiang <hsiang...@linux.alibaba.com> 于2024年6月5日周三 13:18写道:

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

Reply via email to