Re: Several potential vulnerabilities in the filesystem
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, ); //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, ); >> 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, ); >> 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-jnhuan...@gmail.com/T/#u Thanks, Jianan > > Thanks, > Gao Xiang > >> >> Best regards >> >> Gao Xiang 于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 >>>
Re: Several potential vulnerabilities in the filesystem
Could you please forward the issues to whoever is responsible for them? Gao Xiang 于2024年6月5日周三 13:35写道: > > > > 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 于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, ); //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, ); > >>> 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, ); > >>> 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 于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 >
Re: Several potential vulnerabilities in the filesystem
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 于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, ); //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, ); 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, ); 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 于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
Re: Several potential vulnerabilities in the filesystem
Hi Xiang, I just checked the second crash, the patch can solve this issue. Did you also look into the other two issues? Best Jianqiang Gao Xiang 于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, ); //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, ); > > 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, ); > > 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 于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 > >>
Re: Several potential vulnerabilities in the filesystem
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, ); //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, ); 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, ); 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 于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
Re: Several potential vulnerabilities in the filesystem
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, ); //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, ); 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, ); 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 于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 > payload_00763 Description: Binary data payload_00846 Description: Binary data payload_00500 Description: Binary data
Re: Several potential vulnerabilities in the filesystem
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