Security vulnerabilities report to Das-U-Boot

Security vulnerabilities report to Das-U-Boot

[Jonathan Bar Or]

Dear U-boot maintainers,

What is the best way of reporting security vulnerabilities (memory
corruption issues) to Das-U-Boot? Is there a PGP key I should be using?
I have 4 issues that I think are worth fixing (with very easy fixes).

Best regards,
            Jonathan

Re: Security vulnerabilities report to Das-U-Boot

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 564 bytes --]

On Thu, Feb 06, 2025 at 07:47:54PM -0800, Jonathan Bar Or wrote:

> Dear U-boot maintainers,
> 
> What is the best way of reporting security vulnerabilities (memory
> corruption issues) to Das-U-Boot? Is there a PGP key I should be using?
> I have 4 issues that I think are worth fixing (with very easy fixes).
> 
> Best regards,
>             Jonathan

Hey. As per https://docs.u-boot.org/en/latest/develop/security.html
please post them to the list in public. If you have possible solutions
for them as well that's even better. Thanks!

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: Security vulnerabilities report to Das-U-Boot

[Jonathan Bar Or]

[-- Attachment #1: Type: text/plain, Size: 1145 bytes --]

Thank you.

So, I'm attaching my findings in a md file - see attachment.
All of those could be avoided by using safe math, such as
__builtin_mul_overflow and __builtin_add_overflow, which are used in some
modules in Das-U-Boot.
There are many cases where seemingly unsafe addition and multiplication can
cause integer overflows, but not all are exploitable - I believe the ones I
report here are.

Let me know your thoughts.

Best regards,
            Jonathan

On Fri, Feb 7, 2025 at 7:50 AM Tom Rini <trini@konsulko.com> wrote:

> On Thu, Feb 06, 2025 at 07:47:54PM -0800, Jonathan Bar Or wrote:
>
> > Dear U-boot maintainers,
> >
> > What is the best way of reporting security vulnerabilities (memory
> > corruption issues) to Das-U-Boot? Is there a PGP key I should be using?
> > I have 4 issues that I think are worth fixing (with very easy fixes).
> >
> > Best regards,
> >             Jonathan
>
> Hey. As per https://docs.u-boot.org/en/latest/develop/security.html
> please post them to the list in public. If you have possible solutions
> for them as well that's even better. Thanks!
>
> --
> Tom
>

[-- Attachment #2: notes.md --]
[-- Type: text/markdown, Size: 3143 bytes --]

Filesystem-based Das-U-Boot issues.

== erofs

=== Integer overflow leading to buffer overflow in symlink resolution
In file `fs.c`, when resolving symlinks, the function `erofs_off_t` gets an `erofs_inode` argument and performs a lookup on the symlink.  
The function blindly trusts the `i_size` member of the input as such:

```c
    size_t len = vi->i_size;
	char *target;
	int err;

	target = malloc(len + 1);
	if (!target)
		return -ENOMEM;
	target[len] = '\0';

	err = erofs_pread(vi, target, len, 0);
	if (err)
		goto err_out;
```

The `erofs_inode` structure's `i_size` member is defined with the type `erofs_off_t` (which is a 64-bit unsigned integer).  
Thereofre, if supplied as 0xFFFFFFFFFFFFFFFF, the `len + 1` input to `malloc` would overflow to 0, allocating a chunk with 0.  
That chunk (saved in `target`) is later written with `erofs_pread`, overriding the chunk with partial data controlled by an attacker.  
Therefore, we will have a heap buffer overflow due to an integer overflow in `len` calculation.

== squashfs

=== Integer overflow leading to buffer overflow in inode table parsing 
In file `sqfs.c`, function `sqfs_read_inode_table` is responsible of reading an inode table.  
It gets the superblock (attacker controlled) from the context. Then, it employs the following logic:

```c
    n_blks = sqfs_calc_n_blks(sblk->inode_table_start, sblk->directory_table_start, &table_offset);

	/* Allocate a proper sized buffer (itb) to store the inode table */
	itb = malloc_cache_aligned(n_blks * ctxt.cur_dev->blksz);
	if (!itb)
		return -ENOMEM;

	if (sqfs_disk_read(start, n_blks, itb) < 0) {
		ret = -EINVAL;
		goto free_itb;
	}
```

=== Integer overflow leading to buffer overflow in directory table parsing
Similarly to the previous issue in inode table parsing in `sqfs.c`, the same unsafe multiplication exists within the function `sqfs_read_directory_table` responsible for reading the directory table:

```c
    n_blks = sqfs_calc_n_blks(sblk->directory_table_start,
				  sblk->fragment_table_start, &table_offset);

	/* Allocate a proper sized buffer (dtb) to store the directory table */
	dtb = malloc_cache_aligned(n_blks * ctxt.cur_dev->blksz);
	if (!dtb)
		return -ENOMEM;

	if (sqfs_disk_read(start, n_blks, dtb) < 0)
		goto out;
```

The multiplication of `n_blks` and the block size (attacker-controlled 64-bit unsigned integer) is unsafe and might overflow, resulting in an out-of-bounds write.

=== Integer overflow leading to buffer overflow in nested file reading
Similarly to the previous issue in inode table parsing in `sqfs.c`, the same unsafe multiplication exists within the function `sqfs_read_nest` responsible for reading a file:

```c
			data_buffer = malloc_cache_aligned(n_blks * ctxt.cur_dev->blksz);

			if (!data_buffer) {
				ret = -ENOMEM;
				goto out;
			}

			ret = sqfs_disk_read(start, n_blks, data_buffer);
```

A similar issue exists in the same function also later on:

```c
    fragment = malloc_cache_aligned(n_blks * ctxt.cur_dev->blksz);

	if (!fragment) {
		ret = -ENOMEM;
		goto out;
	}

	ret = sqfs_disk_read(start, n_blks, fragment);
	if (ret < 0)
		goto out;
```

Re: Security vulnerabilities report to Das-U-Boot

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 4779 bytes --]

On Fri, Feb 07, 2025 at 09:53:01AM -0800, Jonathan Bar Or wrote:

> Thank you.
> 
> So, I'm attaching my findings in a md file - see attachment.
> All of those could be avoided by using safe math, such as
> __builtin_mul_overflow and __builtin_add_overflow, which are used in some
> modules in Das-U-Boot.
> There are many cases where seemingly unsafe addition and multiplication can
> cause integer overflows, but not all are exploitable - I believe the ones I
> report here are.
> 
> Let me know your thoughts.

Adding in the eorfs and squashfs maintainers..

> 
> Best regards,
>             Jonathan
> 
> On Fri, Feb 7, 2025 at 7:50 AM Tom Rini <trini@konsulko.com> wrote:
> 
> > On Thu, Feb 06, 2025 at 07:47:54PM -0800, Jonathan Bar Or wrote:
> >
> > > Dear U-boot maintainers,
> > >
> > > What is the best way of reporting security vulnerabilities (memory
> > > corruption issues) to Das-U-Boot? Is there a PGP key I should be using?
> > > I have 4 issues that I think are worth fixing (with very easy fixes).
> > >
> > > Best regards,
> > >             Jonathan
> >
> > Hey. As per https://docs.u-boot.org/en/latest/develop/security.html
> > please post them to the list in public. If you have possible solutions
> > for them as well that's even better. Thanks!
> >
> > --
> > Tom
> >

> Filesystem-based Das-U-Boot issues.
> 
> == erofs
> 
> === Integer overflow leading to buffer overflow in symlink resolution
> In file `fs.c`, when resolving symlinks, the function `erofs_off_t` gets an `erofs_inode` argument and performs a lookup on the symlink.  
> The function blindly trusts the `i_size` member of the input as such:
> 
> ```c
>     size_t len = vi->i_size;
> 	char *target;
> 	int err;
> 
> 	target = malloc(len + 1);
> 	if (!target)
> 		return -ENOMEM;
> 	target[len] = '\0';
> 
> 	err = erofs_pread(vi, target, len, 0);
> 	if (err)
> 		goto err_out;
> ```
> 
> The `erofs_inode` structure's `i_size` member is defined with the type `erofs_off_t` (which is a 64-bit unsigned integer).  
> Thereofre, if supplied as 0xFFFFFFFFFFFFFFFF, the `len + 1` input to `malloc` would overflow to 0, allocating a chunk with 0.  
> That chunk (saved in `target`) is later written with `erofs_pread`, overriding the chunk with partial data controlled by an attacker.  
> Therefore, we will have a heap buffer overflow due to an integer overflow in `len` calculation.
> 
> == squashfs
> 
> === Integer overflow leading to buffer overflow in inode table parsing 
> In file `sqfs.c`, function `sqfs_read_inode_table` is responsible of reading an inode table.  
> It gets the superblock (attacker controlled) from the context. Then, it employs the following logic:
> 
> ```c
>     n_blks = sqfs_calc_n_blks(sblk->inode_table_start, sblk->directory_table_start, &table_offset);
> 
> 	/* Allocate a proper sized buffer (itb) to store the inode table */
> 	itb = malloc_cache_aligned(n_blks * ctxt.cur_dev->blksz);
> 	if (!itb)
> 		return -ENOMEM;
> 
> 	if (sqfs_disk_read(start, n_blks, itb) < 0) {
> 		ret = -EINVAL;
> 		goto free_itb;
> 	}
> ```
> 
> === Integer overflow leading to buffer overflow in directory table parsing
> Similarly to the previous issue in inode table parsing in `sqfs.c`, the same unsafe multiplication exists within the function `sqfs_read_directory_table` responsible for reading the directory table:
> 
> ```c
>     n_blks = sqfs_calc_n_blks(sblk->directory_table_start,
> 				  sblk->fragment_table_start, &table_offset);
> 
> 	/* Allocate a proper sized buffer (dtb) to store the directory table */
> 	dtb = malloc_cache_aligned(n_blks * ctxt.cur_dev->blksz);
> 	if (!dtb)
> 		return -ENOMEM;
> 
> 	if (sqfs_disk_read(start, n_blks, dtb) < 0)
> 		goto out;
> ```
> 
> The multiplication of `n_blks` and the block size (attacker-controlled 64-bit unsigned integer) is unsafe and might overflow, resulting in an out-of-bounds write.
> 
> === Integer overflow leading to buffer overflow in nested file reading
> Similarly to the previous issue in inode table parsing in `sqfs.c`, the same unsafe multiplication exists within the function `sqfs_read_nest` responsible for reading a file:
> 
> ```c
> 			data_buffer = malloc_cache_aligned(n_blks * ctxt.cur_dev->blksz);
> 
> 			if (!data_buffer) {
> 				ret = -ENOMEM;
> 				goto out;
> 			}
> 
> 			ret = sqfs_disk_read(start, n_blks, data_buffer);
> ```
> 
> A similar issue exists in the same function also later on:
> 
> ```c
>     fragment = malloc_cache_aligned(n_blks * ctxt.cur_dev->blksz);
> 
> 	if (!fragment) {
> 		ret = -ENOMEM;
> 		goto out;
> 	}
> 
> 	ret = sqfs_disk_read(start, n_blks, fragment);
> 	if (ret < 0)
> 		goto out;
> ```
> 


-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: Security vulnerabilities report to Das-U-Boot

[Gao Xiang]

Hi Tom,

On 2025/2/11 00:41, Tom Rini wrote:
> On Fri, Feb 07, 2025 at 09:53:01AM -0800, Jonathan Bar Or wrote:
> 
>> Thank you.
>>
>> So, I'm attaching my findings in a md file - see attachment.
>> All of those could be avoided by using safe math, such as
>> __builtin_mul_overflow and __builtin_add_overflow, which are used in some
>> modules in Das-U-Boot.
>> There are many cases where seemingly unsafe addition and multiplication can
>> cause integer overflows, but not all are exploitable - I believe the ones I
>> report here are.
>>
>> Let me know your thoughts.
> 
> Adding in the eorfs and squashfs maintainers..
> 
>>
>> Best regards,
>>              Jonathan
>>
>> On Fri, Feb 7, 2025 at 7:50 AM Tom Rini <trini@konsulko.com> wrote:
>>
>>> On Thu, Feb 06, 2025 at 07:47:54PM -0800, Jonathan Bar Or wrote:
>>>
>>>> Dear U-boot maintainers,
>>>>
>>>> What is the best way of reporting security vulnerabilities (memory
>>>> corruption issues) to Das-U-Boot? Is there a PGP key I should be using?
>>>> I have 4 issues that I think are worth fixing (with very easy fixes).
>>>>
>>>> Best regards,
>>>>              Jonathan
>>>
>>> Hey. As per https://docs.u-boot.org/en/latest/develop/security.html
>>> please post them to the list in public. If you have possible solutions
>>> for them as well that's even better. Thanks!
>>>
>>> --
>>> Tom
>>>
> 
>> Filesystem-based Das-U-Boot issues.
>>
>> == erofs
>>
>> === Integer overflow leading to buffer overflow in symlink resolution
>> In file `fs.c`, when resolving symlinks, the function `erofs_off_t` gets an `erofs_inode` argument and performs a lookup on the symlink.
>> The function blindly trusts the `i_size` member of the input as such:
>>
>> ```c
>>      size_t len = vi->i_size;
>> 	char *target;
>> 	int err;
>>
>> 	target = malloc(len + 1);
>> 	if (!target)
>> 		return -ENOMEM;
>> 	target[len] = '\0';
>>
>> 	err = erofs_pread(vi, target, len, 0);
>> 	if (err)
>> 		goto err_out;
>> ```
>>
>> The `erofs_inode` structure's `i_size` member is defined with the type `erofs_off_t` (which is a 64-bit unsigned integer).
>> Thereofre, if supplied as 0xFFFFFFFFFFFFFFFF, the `len + 1` input to `malloc` would overflow to 0, allocating a chunk with 0.
>> That chunk (saved in `target`) is later written with `erofs_pread`, overriding the chunk with partial data controlled by an attacker.
>> Therefore, we will have a heap buffer overflow due to an integer overflow in `len` calculation.

Yeah, it's a corner case, I will try to address it later.

Thanks,
Gao Xiang

Re: Security vulnerabilities report to Das-U-Boot

[Jonathan Bar Or]

Hi Tom and the rest of the team,

Please let me know about fix time, whether this is acknowledged and
whether you're going to request CVE IDs for those or if I should do
it.
The reason is that I found similar issues in other bootloaders, so I'm
trying to synchronize all of them. For what it's worth, Barebox has
similar issues and are currently fixing.

Best regards,
             Jonathan

On Mon, Feb 10, 2025 at 7:51 PM Gao Xiang <hsiangkao@linux.alibaba.com> wrote:
>
> Hi Tom,
>
> On 2025/2/11 00:41, Tom Rini wrote:
> > On Fri, Feb 07, 2025 at 09:53:01AM -0800, Jonathan Bar Or wrote:
> >
> >> Thank you.
> >>
> >> So, I'm attaching my findings in a md file - see attachment.
> >> All of those could be avoided by using safe math, such as
> >> __builtin_mul_overflow and __builtin_add_overflow, which are used in some
> >> modules in Das-U-Boot.
> >> There are many cases where seemingly unsafe addition and multiplication can
> >> cause integer overflows, but not all are exploitable - I believe the ones I
> >> report here are.
> >>
> >> Let me know your thoughts.
> >
> > Adding in the eorfs and squashfs maintainers..
> >
> >>
> >> Best regards,
> >>              Jonathan
> >>
> >> On Fri, Feb 7, 2025 at 7:50 AM Tom Rini <trini@konsulko.com> wrote:
> >>
> >>> On Thu, Feb 06, 2025 at 07:47:54PM -0800, Jonathan Bar Or wrote:
> >>>
> >>>> Dear U-boot maintainers,
> >>>>
> >>>> What is the best way of reporting security vulnerabilities (memory
> >>>> corruption issues) to Das-U-Boot? Is there a PGP key I should be using?
> >>>> I have 4 issues that I think are worth fixing (with very easy fixes).
> >>>>
> >>>> Best regards,
> >>>>              Jonathan
> >>>
> >>> Hey. As per https://docs.u-boot.org/en/latest/develop/security.html
> >>> please post them to the list in public. If you have possible solutions
> >>> for them as well that's even better. Thanks!
> >>>
> >>> --
> >>> Tom
> >>>
> >
> >> Filesystem-based Das-U-Boot issues.
> >>
> >> == erofs
> >>
> >> === Integer overflow leading to buffer overflow in symlink resolution
> >> In file `fs.c`, when resolving symlinks, the function `erofs_off_t` gets an `erofs_inode` argument and performs a lookup on the symlink.
> >> The function blindly trusts the `i_size` member of the input as such:
> >>
> >> ```c
> >>      size_t len = vi->i_size;
> >>      char *target;
> >>      int err;
> >>
> >>      target = malloc(len + 1);
> >>      if (!target)
> >>              return -ENOMEM;
> >>      target[len] = '\0';
> >>
> >>      err = erofs_pread(vi, target, len, 0);
> >>      if (err)
> >>              goto err_out;
> >> ```
> >>
> >> The `erofs_inode` structure's `i_size` member is defined with the type `erofs_off_t` (which is a 64-bit unsigned integer).
> >> Thereofre, if supplied as 0xFFFFFFFFFFFFFFFF, the `len + 1` input to `malloc` would overflow to 0, allocating a chunk with 0.
> >> That chunk (saved in `target`) is later written with `erofs_pread`, overriding the chunk with partial data controlled by an attacker.
> >> Therefore, we will have a heap buffer overflow due to an integer overflow in `len` calculation.
>
> Yeah, it's a corner case, I will try to address it later.
>
> Thanks,
> Gao Xiang

Re: Security vulnerabilities report to Das-U-Boot

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 3768 bytes --]

On Tue, Feb 11, 2025 at 08:26:37AM -0800, Jonathan Bar Or wrote:
> Hi Tom and the rest of the team,
> 
> Please let me know about fix time, whether this is acknowledged and
> whether you're going to request CVE IDs for those or if I should do
> it.
> The reason is that I found similar issues in other bootloaders, so I'm
> trying to synchronize all of them. For what it's worth, Barebox has
> similar issues and are currently fixing.

Yes, these seem valid. We don't have a CVE requesting authority so if
you want them, go ahead and request them. You saw Gao Xiang's response
for erofs, and I'm hoping one of the squashfs maintainers will chime in.

> 
> Best regards,
>              Jonathan
> 
> On Mon, Feb 10, 2025 at 7:51 PM Gao Xiang <hsiangkao@linux.alibaba.com> wrote:
> >
> > Hi Tom,
> >
> > On 2025/2/11 00:41, Tom Rini wrote:
> > > On Fri, Feb 07, 2025 at 09:53:01AM -0800, Jonathan Bar Or wrote:
> > >
> > >> Thank you.
> > >>
> > >> So, I'm attaching my findings in a md file - see attachment.
> > >> All of those could be avoided by using safe math, such as
> > >> __builtin_mul_overflow and __builtin_add_overflow, which are used in some
> > >> modules in Das-U-Boot.
> > >> There are many cases where seemingly unsafe addition and multiplication can
> > >> cause integer overflows, but not all are exploitable - I believe the ones I
> > >> report here are.
> > >>
> > >> Let me know your thoughts.
> > >
> > > Adding in the eorfs and squashfs maintainers..
> > >
> > >>
> > >> Best regards,
> > >>              Jonathan
> > >>
> > >> On Fri, Feb 7, 2025 at 7:50 AM Tom Rini <trini@konsulko.com> wrote:
> > >>
> > >>> On Thu, Feb 06, 2025 at 07:47:54PM -0800, Jonathan Bar Or wrote:
> > >>>
> > >>>> Dear U-boot maintainers,
> > >>>>
> > >>>> What is the best way of reporting security vulnerabilities (memory
> > >>>> corruption issues) to Das-U-Boot? Is there a PGP key I should be using?
> > >>>> I have 4 issues that I think are worth fixing (with very easy fixes).
> > >>>>
> > >>>> Best regards,
> > >>>>              Jonathan
> > >>>
> > >>> Hey. As per https://docs.u-boot.org/en/latest/develop/security.html
> > >>> please post them to the list in public. If you have possible solutions
> > >>> for them as well that's even better. Thanks!
> > >>>
> > >>> --
> > >>> Tom
> > >>>
> > >
> > >> Filesystem-based Das-U-Boot issues.
> > >>
> > >> == erofs
> > >>
> > >> === Integer overflow leading to buffer overflow in symlink resolution
> > >> In file `fs.c`, when resolving symlinks, the function `erofs_off_t` gets an `erofs_inode` argument and performs a lookup on the symlink.
> > >> The function blindly trusts the `i_size` member of the input as such:
> > >>
> > >> ```c
> > >>      size_t len = vi->i_size;
> > >>      char *target;
> > >>      int err;
> > >>
> > >>      target = malloc(len + 1);
> > >>      if (!target)
> > >>              return -ENOMEM;
> > >>      target[len] = '\0';
> > >>
> > >>      err = erofs_pread(vi, target, len, 0);
> > >>      if (err)
> > >>              goto err_out;
> > >> ```
> > >>
> > >> The `erofs_inode` structure's `i_size` member is defined with the type `erofs_off_t` (which is a 64-bit unsigned integer).
> > >> Thereofre, if supplied as 0xFFFFFFFFFFFFFFFF, the `len + 1` input to `malloc` would overflow to 0, allocating a chunk with 0.
> > >> That chunk (saved in `target`) is later written with `erofs_pread`, overriding the chunk with partial data controlled by an attacker.
> > >> Therefore, we will have a heap buffer overflow due to an integer overflow in `len` calculation.
> >
> > Yeah, it's a corner case, I will try to address it later.
> >
> > Thanks,
> > Gao Xiang

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: Security vulnerabilities report to Das-U-Boot

[Jonathan Bar Or]

Thank you, I've reached out to MITRE for CVE numbers, I will
communicate them once assigned (hopefully within a few days).

Best regards,
              Jonathan

On Tue, Feb 11, 2025 at 1:29 PM Tom Rini <trini@konsulko.com> wrote:
>
> On Tue, Feb 11, 2025 at 08:26:37AM -0800, Jonathan Bar Or wrote:
> > Hi Tom and the rest of the team,
> >
> > Please let me know about fix time, whether this is acknowledged and
> > whether you're going to request CVE IDs for those or if I should do
> > it.
> > The reason is that I found similar issues in other bootloaders, so I'm
> > trying to synchronize all of them. For what it's worth, Barebox has
> > similar issues and are currently fixing.
>
> Yes, these seem valid. We don't have a CVE requesting authority so if
> you want them, go ahead and request them. You saw Gao Xiang's response
> for erofs, and I'm hoping one of the squashfs maintainers will chime in.
>
> >
> > Best regards,
> >              Jonathan
> >
> > On Mon, Feb 10, 2025 at 7:51 PM Gao Xiang <hsiangkao@linux.alibaba.com> wrote:
> > >
> > > Hi Tom,
> > >
> > > On 2025/2/11 00:41, Tom Rini wrote:
> > > > On Fri, Feb 07, 2025 at 09:53:01AM -0800, Jonathan Bar Or wrote:
> > > >
> > > >> Thank you.
> > > >>
> > > >> So, I'm attaching my findings in a md file - see attachment.
> > > >> All of those could be avoided by using safe math, such as
> > > >> __builtin_mul_overflow and __builtin_add_overflow, which are used in some
> > > >> modules in Das-U-Boot.
> > > >> There are many cases where seemingly unsafe addition and multiplication can
> > > >> cause integer overflows, but not all are exploitable - I believe the ones I
> > > >> report here are.
> > > >>
> > > >> Let me know your thoughts.
> > > >
> > > > Adding in the eorfs and squashfs maintainers..
> > > >
> > > >>
> > > >> Best regards,
> > > >>              Jonathan
> > > >>
> > > >> On Fri, Feb 7, 2025 at 7:50 AM Tom Rini <trini@konsulko.com> wrote:
> > > >>
> > > >>> On Thu, Feb 06, 2025 at 07:47:54PM -0800, Jonathan Bar Or wrote:
> > > >>>
> > > >>>> Dear U-boot maintainers,
> > > >>>>
> > > >>>> What is the best way of reporting security vulnerabilities (memory
> > > >>>> corruption issues) to Das-U-Boot? Is there a PGP key I should be using?
> > > >>>> I have 4 issues that I think are worth fixing (with very easy fixes).
> > > >>>>
> > > >>>> Best regards,
> > > >>>>              Jonathan
> > > >>>
> > > >>> Hey. As per https://docs.u-boot.org/en/latest/develop/security.html
> > > >>> please post them to the list in public. If you have possible solutions
> > > >>> for them as well that's even better. Thanks!
> > > >>>
> > > >>> --
> > > >>> Tom
> > > >>>
> > > >
> > > >> Filesystem-based Das-U-Boot issues.
> > > >>
> > > >> == erofs
> > > >>
> > > >> === Integer overflow leading to buffer overflow in symlink resolution
> > > >> In file `fs.c`, when resolving symlinks, the function `erofs_off_t` gets an `erofs_inode` argument and performs a lookup on the symlink.
> > > >> The function blindly trusts the `i_size` member of the input as such:
> > > >>
> > > >> ```c
> > > >>      size_t len = vi->i_size;
> > > >>      char *target;
> > > >>      int err;
> > > >>
> > > >>      target = malloc(len + 1);
> > > >>      if (!target)
> > > >>              return -ENOMEM;
> > > >>      target[len] = '\0';
> > > >>
> > > >>      err = erofs_pread(vi, target, len, 0);
> > > >>      if (err)
> > > >>              goto err_out;
> > > >> ```
> > > >>
> > > >> The `erofs_inode` structure's `i_size` member is defined with the type `erofs_off_t` (which is a 64-bit unsigned integer).
> > > >> Thereofre, if supplied as 0xFFFFFFFFFFFFFFFF, the `len + 1` input to `malloc` would overflow to 0, allocating a chunk with 0.
> > > >> That chunk (saved in `target`) is later written with `erofs_pread`, overriding the chunk with partial data controlled by an attacker.
> > > >> Therefore, we will have a heap buffer overflow due to an integer overflow in `len` calculation.
> > >
> > > Yeah, it's a corner case, I will try to address it later.
> > >
> > > Thanks,
> > > Gao Xiang
>
> --
> Tom

Re: Security vulnerabilities report to Das-U-Boot

[Miquel Raynal]

Hello Tom,

On 11/02/2025 at 15:29:09 -06, Tom Rini <trini@konsulko.com> wrote:

> On Tue, Feb 11, 2025 at 08:26:37AM -0800, Jonathan Bar Or wrote:
>> Hi Tom and the rest of the team,
>> 
>> Please let me know about fix time, whether this is acknowledged and
>> whether you're going to request CVE IDs for those or if I should do
>> it.
>> The reason is that I found similar issues in other bootloaders, so I'm
>> trying to synchronize all of them. For what it's worth, Barebox has
>> similar issues and are currently fixing.
>
> Yes, these seem valid. We don't have a CVE requesting authority so if
> you want them, go ahead and request them. You saw Gao Xiang's response
> for erofs, and I'm hoping one of the squashfs maintainers will chime
> in.

Either João or me, we will have a look.

Thanks,
Miquèl

Re: Security vulnerabilities report to Das-U-Boot

[Jonathan Bar Or]

Hi folks.

Here are the CVEs assigned by MITRE:
- CVE-2025-26721: buffer overflow in the persistent storage for file creation
- CVE-2025-26722: buffer overflow in SquashFS symlink resolution
- CVE-2025-26723: buffer overflow in EXT4 symlink resolution
- CVE-2025-26724: buffer overflow in CramFS symlink resolution
- CVE-2025-26724: buffer overflow in JFFS2 dirent parsing

Best regards,
           Jonathan

On Wed, Feb 12, 2025 at 12:24 AM Miquel Raynal
<miquel.raynal@bootlin.com> wrote:
>
> Hello Tom,
>
> On 11/02/2025 at 15:29:09 -06, Tom Rini <trini@konsulko.com> wrote:
>
> > On Tue, Feb 11, 2025 at 08:26:37AM -0800, Jonathan Bar Or wrote:
> >> Hi Tom and the rest of the team,
> >>
> >> Please let me know about fix time, whether this is acknowledged and
> >> whether you're going to request CVE IDs for those or if I should do
> >> it.
> >> The reason is that I found similar issues in other bootloaders, so I'm
> >> trying to synchronize all of them. For what it's worth, Barebox has
> >> similar issues and are currently fixing.
> >
> > Yes, these seem valid. We don't have a CVE requesting authority so if
> > you want them, go ahead and request them. You saw Gao Xiang's response
> > for erofs, and I'm hoping one of the squashfs maintainers will chime
> > in.
>
> Either João or me, we will have a look.
>
> Thanks,
> Miquèl

Re: Security vulnerabilities report to Das-U-Boot

[Jonathan Bar Or]

Please disregard the previous message, those are the actual CVE numbers:

- CVE-2025-26726 :SquashFS directory table parsing buffer overflow
- CVE-2025-26727: SquashFS inode parsing buffer overflow.
- CVE-2025-26728: SquashFS nested file reading buffer overflow.
- CVE-2025-26729: EroFS symlink resolution buffer overflow.

Best regards,
           Jonathan


On Fri, Feb 14, 2025 at 7:17 PM Jonathan Bar Or <jonathanbaror@gmail.com> wrote:
>
> Hi folks.
>
> Here are the CVEs assigned by MITRE:
> - CVE-2025-26721: buffer overflow in the persistent storage for file creation
> - CVE-2025-26722: buffer overflow in SquashFS symlink resolution
> - CVE-2025-26723: buffer overflow in EXT4 symlink resolution
> - CVE-2025-26724: buffer overflow in CramFS symlink resolution
> - CVE-2025-26724: buffer overflow in JFFS2 dirent parsing
>
> Best regards,
>            Jonathan
>
> On Wed, Feb 12, 2025 at 12:24 AM Miquel Raynal
> <miquel.raynal@bootlin.com> wrote:
> >
> > Hello Tom,
> >
> > On 11/02/2025 at 15:29:09 -06, Tom Rini <trini@konsulko.com> wrote:
> >
> > > On Tue, Feb 11, 2025 at 08:26:37AM -0800, Jonathan Bar Or wrote:
> > >> Hi Tom and the rest of the team,
> > >>
> > >> Please let me know about fix time, whether this is acknowledged and
> > >> whether you're going to request CVE IDs for those or if I should do
> > >> it.
> > >> The reason is that I found similar issues in other bootloaders, so I'm
> > >> trying to synchronize all of them. For what it's worth, Barebox has
> > >> similar issues and are currently fixing.
> > >
> > > Yes, these seem valid. We don't have a CVE requesting authority so if
> > > you want them, go ahead and request them. You saw Gao Xiang's response
> > > for erofs, and I'm hoping one of the squashfs maintainers will chime
> > > in.
> >
> > Either João or me, we will have a look.
> >
> > Thanks,
> > Miquèl

Re: Security vulnerabilities report to Das-U-Boot

[Jonathan Bar Or]

Hello Tom and team,

Looks like all of the issues were fixed and merged - am I correct?
I intend to make a public disclosure March 19th, is that okay?

Best,
       Jonathan

On Fri, Feb 14, 2025 at 7:24 PM Jonathan Bar Or <jonathanbaror@gmail.com> wrote:
>
> Please disregard the previous message, those are the actual CVE numbers:
>
> - CVE-2025-26726 :SquashFS directory table parsing buffer overflow
> - CVE-2025-26727: SquashFS inode parsing buffer overflow.
> - CVE-2025-26728: SquashFS nested file reading buffer overflow.
> - CVE-2025-26729: EroFS symlink resolution buffer overflow.
>
> Best regards,
>            Jonathan
>
>
> On Fri, Feb 14, 2025 at 7:17 PM Jonathan Bar Or <jonathanbaror@gmail.com> wrote:
> >
> > Hi folks.
> >
> > Here are the CVEs assigned by MITRE:
> > - CVE-2025-26721: buffer overflow in the persistent storage for file creation
> > - CVE-2025-26722: buffer overflow in SquashFS symlink resolution
> > - CVE-2025-26723: buffer overflow in EXT4 symlink resolution
> > - CVE-2025-26724: buffer overflow in CramFS symlink resolution
> > - CVE-2025-26724: buffer overflow in JFFS2 dirent parsing
> >
> > Best regards,
> >            Jonathan
> >
> > On Wed, Feb 12, 2025 at 12:24 AM Miquel Raynal
> > <miquel.raynal@bootlin.com> wrote:
> > >
> > > Hello Tom,
> > >
> > > On 11/02/2025 at 15:29:09 -06, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > > On Tue, Feb 11, 2025 at 08:26:37AM -0800, Jonathan Bar Or wrote:
> > > >> Hi Tom and the rest of the team,
> > > >>
> > > >> Please let me know about fix time, whether this is acknowledged and
> > > >> whether you're going to request CVE IDs for those or if I should do
> > > >> it.
> > > >> The reason is that I found similar issues in other bootloaders, so I'm
> > > >> trying to synchronize all of them. For what it's worth, Barebox has
> > > >> similar issues and are currently fixing.
> > > >
> > > > Yes, these seem valid. We don't have a CVE requesting authority so if
> > > > you want them, go ahead and request them. You saw Gao Xiang's response
> > > > for erofs, and I'm hoping one of the squashfs maintainers will chime
> > > > in.
> > >
> > > Either João or me, we will have a look.
> > >
> > > Thanks,
> > > Miquèl

Re: Security vulnerabilities report to Das-U-Boot

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 2553 bytes --]

On Sat, Feb 22, 2025 at 12:47:45PM -0800, Jonathan Bar Or wrote:

> Hello Tom and team,
> 
> Looks like all of the issues were fixed and merged - am I correct?
> I intend to make a public disclosure March 19th, is that okay?

Yes, I've merged all of the patches I'm aware of at this point.

> 
> Best,
>        Jonathan
> 
> On Fri, Feb 14, 2025 at 7:24 PM Jonathan Bar Or <jonathanbaror@gmail.com> wrote:
> >
> > Please disregard the previous message, those are the actual CVE numbers:
> >
> > - CVE-2025-26726 :SquashFS directory table parsing buffer overflow
> > - CVE-2025-26727: SquashFS inode parsing buffer overflow.
> > - CVE-2025-26728: SquashFS nested file reading buffer overflow.
> > - CVE-2025-26729: EroFS symlink resolution buffer overflow.
> >
> > Best regards,
> >            Jonathan
> >
> >
> > On Fri, Feb 14, 2025 at 7:17 PM Jonathan Bar Or <jonathanbaror@gmail.com> wrote:
> > >
> > > Hi folks.
> > >
> > > Here are the CVEs assigned by MITRE:
> > > - CVE-2025-26721: buffer overflow in the persistent storage for file creation
> > > - CVE-2025-26722: buffer overflow in SquashFS symlink resolution
> > > - CVE-2025-26723: buffer overflow in EXT4 symlink resolution
> > > - CVE-2025-26724: buffer overflow in CramFS symlink resolution
> > > - CVE-2025-26724: buffer overflow in JFFS2 dirent parsing
> > >
> > > Best regards,
> > >            Jonathan
> > >
> > > On Wed, Feb 12, 2025 at 12:24 AM Miquel Raynal
> > > <miquel.raynal@bootlin.com> wrote:
> > > >
> > > > Hello Tom,
> > > >
> > > > On 11/02/2025 at 15:29:09 -06, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > > On Tue, Feb 11, 2025 at 08:26:37AM -0800, Jonathan Bar Or wrote:
> > > > >> Hi Tom and the rest of the team,
> > > > >>
> > > > >> Please let me know about fix time, whether this is acknowledged and
> > > > >> whether you're going to request CVE IDs for those or if I should do
> > > > >> it.
> > > > >> The reason is that I found similar issues in other bootloaders, so I'm
> > > > >> trying to synchronize all of them. For what it's worth, Barebox has
> > > > >> similar issues and are currently fixing.
> > > > >
> > > > > Yes, these seem valid. We don't have a CVE requesting authority so if
> > > > > you want them, go ahead and request them. You saw Gao Xiang's response
> > > > > for erofs, and I'm hoping one of the squashfs maintainers will chime
> > > > > in.
> > > >
> > > > Either João or me, we will have a look.
> > > >
> > > > Thanks,
> > > > Miquèl

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: Security vulnerabilities report to Das-U-Boot

[Jonathan Bar Or]

Awesome, thanks for the update!

On Tue, Feb 25, 2025, 9:59 AM Tom Rini <trini@konsulko.com> wrote:

> On Sat, Feb 22, 2025 at 12:47:45PM -0800, Jonathan Bar Or wrote:
>
> > Hello Tom and team,
> >
> > Looks like all of the issues were fixed and merged - am I correct?
> > I intend to make a public disclosure March 19th, is that okay?
>
> Yes, I've merged all of the patches I'm aware of at this point.
>
> >
> > Best,
> >        Jonathan
> >
> > On Fri, Feb 14, 2025 at 7:24 PM Jonathan Bar Or <jonathanbaror@gmail.com>
> wrote:
> > >
> > > Please disregard the previous message, those are the actual CVE
> numbers:
> > >
> > > - CVE-2025-26726 :SquashFS directory table parsing buffer overflow
> > > - CVE-2025-26727: SquashFS inode parsing buffer overflow.
> > > - CVE-2025-26728: SquashFS nested file reading buffer overflow.
> > > - CVE-2025-26729: EroFS symlink resolution buffer overflow.
> > >
> > > Best regards,
> > >            Jonathan
> > >
> > >
> > > On Fri, Feb 14, 2025 at 7:17 PM Jonathan Bar Or <
> jonathanbaror@gmail.com> wrote:
> > > >
> > > > Hi folks.
> > > >
> > > > Here are the CVEs assigned by MITRE:
> > > > - CVE-2025-26721: buffer overflow in the persistent storage for file
> creation
> > > > - CVE-2025-26722: buffer overflow in SquashFS symlink resolution
> > > > - CVE-2025-26723: buffer overflow in EXT4 symlink resolution
> > > > - CVE-2025-26724: buffer overflow in CramFS symlink resolution
> > > > - CVE-2025-26724: buffer overflow in JFFS2 dirent parsing
> > > >
> > > > Best regards,
> > > >            Jonathan
> > > >
> > > > On Wed, Feb 12, 2025 at 12:24 AM Miquel Raynal
> > > > <miquel.raynal@bootlin.com> wrote:
> > > > >
> > > > > Hello Tom,
> > > > >
> > > > > On 11/02/2025 at 15:29:09 -06, Tom Rini <trini@konsulko.com>
> wrote:
> > > > >
> > > > > > On Tue, Feb 11, 2025 at 08:26:37AM -0800, Jonathan Bar Or wrote:
> > > > > >> Hi Tom and the rest of the team,
> > > > > >>
> > > > > >> Please let me know about fix time, whether this is acknowledged
> and
> > > > > >> whether you're going to request CVE IDs for those or if I
> should do
> > > > > >> it.
> > > > > >> The reason is that I found similar issues in other bootloaders,
> so I'm
> > > > > >> trying to synchronize all of them. For what it's worth, Barebox
> has
> > > > > >> similar issues and are currently fixing.
> > > > > >
> > > > > > Yes, these seem valid. We don't have a CVE requesting authority
> so if
> > > > > > you want them, go ahead and request them. You saw Gao Xiang's
> response
> > > > > > for erofs, and I'm hoping one of the squashfs maintainers will
> chime
> > > > > > in.
> > > > >
> > > > > Either João or me, we will have a look.
> > > > >
> > > > > Thanks,
> > > > > Miquèl
>
> --
> Tom
>