* Security vulnerabilities report to Das-U-Boot
@ 2025-02-07 3:47 Jonathan Bar Or
2025-02-07 15:50 ` Tom Rini
0 siblings, 1 reply; 23+ messages in thread
From: Jonathan Bar Or @ 2025-02-07 3:47 UTC (permalink / raw)
To: u-boot, trini
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Security vulnerabilities report to Das-U-Boot
2025-02-07 3:47 Security vulnerabilities report to Das-U-Boot Jonathan Bar Or
@ 2025-02-07 15:50 ` Tom Rini
2025-02-07 17:53 ` Jonathan Bar Or
0 siblings, 1 reply; 23+ messages in thread
From: Tom Rini @ 2025-02-07 15:50 UTC (permalink / raw)
To: Jonathan Bar Or; +Cc: u-boot
[-- 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 --]
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Security vulnerabilities report to Das-U-Boot
2025-02-07 15:50 ` Tom Rini
@ 2025-02-07 17:53 ` Jonathan Bar Or
2025-02-10 16:41 ` Tom Rini
0 siblings, 1 reply; 23+ messages in thread
From: Jonathan Bar Or @ 2025-02-07 17:53 UTC (permalink / raw)
To: Tom Rini; +Cc: u-boot
[-- 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;
```
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Security vulnerabilities report to Das-U-Boot
2025-02-07 17:53 ` Jonathan Bar Or
@ 2025-02-10 16:41 ` Tom Rini
2025-02-11 3:51 ` Gao Xiang
0 siblings, 1 reply; 23+ messages in thread
From: Tom Rini @ 2025-02-10 16:41 UTC (permalink / raw)
To: Jonathan Bar Or, Huang Jianan, Joao Marcos Costa,
Thomas Petazzoni, Miquel Raynal
Cc: u-boot, linux-erofs
[-- 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 --]
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Security vulnerabilities report to Das-U-Boot
2025-02-10 16:41 ` Tom Rini
@ 2025-02-11 3:51 ` Gao Xiang
2025-02-11 16:26 ` Jonathan Bar Or
0 siblings, 1 reply; 23+ messages in thread
From: Gao Xiang @ 2025-02-11 3:51 UTC (permalink / raw)
To: Tom Rini, Jonathan Bar Or, Huang Jianan, Joao Marcos Costa,
Thomas Petazzoni, Miquel Raynal
Cc: u-boot, linux-erofs
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Security vulnerabilities report to Das-U-Boot
2025-02-11 3:51 ` Gao Xiang
@ 2025-02-11 16:26 ` Jonathan Bar Or
0 siblings, 0 replies; 23+ messages in thread
From: Jonathan Bar Or @ 2025-02-11 16:26 UTC (permalink / raw)
To: Gao Xiang
Cc: Tom Rini, Joao Marcos Costa, u-boot, Thomas Petazzoni,
Miquel Raynal, linux-erofs
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Security vulnerabilities report to Das-U-Boot
@ 2025-02-11 16:26 ` Jonathan Bar Or
0 siblings, 0 replies; 23+ messages in thread
From: Jonathan Bar Or @ 2025-02-11 16:26 UTC (permalink / raw)
To: Gao Xiang
Cc: Tom Rini, Huang Jianan, Joao Marcos Costa, Thomas Petazzoni,
Miquel Raynal, u-boot, linux-erofs
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Security vulnerabilities report to Das-U-Boot
2025-02-11 16:26 ` Jonathan Bar Or
@ 2025-02-11 21:29 ` Tom Rini
-1 siblings, 0 replies; 23+ messages in thread
From: Tom Rini @ 2025-02-11 21:29 UTC (permalink / raw)
To: Jonathan Bar Or
Cc: Joao Marcos Costa, u-boot, Thomas Petazzoni, Miquel Raynal,
Gao Xiang, linux-erofs
[-- 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 --]
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Security vulnerabilities report to Das-U-Boot
@ 2025-02-11 21:29 ` Tom Rini
0 siblings, 0 replies; 23+ messages in thread
From: Tom Rini @ 2025-02-11 21:29 UTC (permalink / raw)
To: Jonathan Bar Or
Cc: Gao Xiang, Huang Jianan, Joao Marcos Costa, Thomas Petazzoni,
Miquel Raynal, u-boot, linux-erofs
[-- 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 --]
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Security vulnerabilities report to Das-U-Boot
2025-02-11 21:29 ` Tom Rini
@ 2025-02-11 23:28 ` Jonathan Bar Or
-1 siblings, 0 replies; 23+ messages in thread
From: Jonathan Bar Or @ 2025-02-11 23:28 UTC (permalink / raw)
To: Tom Rini
Cc: Joao Marcos Costa, u-boot, Thomas Petazzoni, Miquel Raynal,
Gao Xiang, linux-erofs
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Security vulnerabilities report to Das-U-Boot
@ 2025-02-11 23:28 ` Jonathan Bar Or
0 siblings, 0 replies; 23+ messages in thread
From: Jonathan Bar Or @ 2025-02-11 23:28 UTC (permalink / raw)
To: Tom Rini
Cc: Gao Xiang, Huang Jianan, Joao Marcos Costa, Thomas Petazzoni,
Miquel Raynal, u-boot, linux-erofs
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Security vulnerabilities report to Das-U-Boot
2025-02-11 21:29 ` Tom Rini
@ 2025-02-12 8:24 ` Miquel Raynal
-1 siblings, 0 replies; 23+ messages in thread
From: Miquel Raynal via Linux-erofs @ 2025-02-12 8:24 UTC (permalink / raw)
To: Tom Rini
Cc: u-boot, Joao Marcos Costa, Jonathan Bar Or, Thomas Petazzoni,
Gao Xiang, linux-erofs
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Security vulnerabilities report to Das-U-Boot
@ 2025-02-12 8:24 ` Miquel Raynal
0 siblings, 0 replies; 23+ messages in thread
From: Miquel Raynal @ 2025-02-12 8:24 UTC (permalink / raw)
To: Tom Rini
Cc: Jonathan Bar Or, Gao Xiang, Huang Jianan, Joao Marcos Costa,
Thomas Petazzoni, u-boot, linux-erofs
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Security vulnerabilities report to Das-U-Boot
2025-02-12 8:24 ` Miquel Raynal
@ 2025-02-15 3:17 ` Jonathan Bar Or
-1 siblings, 0 replies; 23+ messages in thread
From: Jonathan Bar Or @ 2025-02-15 3:17 UTC (permalink / raw)
To: Miquel Raynal
Cc: Tom Rini, u-boot, Joao Marcos Costa, Thomas Petazzoni, Gao Xiang,
linux-erofs
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Security vulnerabilities report to Das-U-Boot
@ 2025-02-15 3:17 ` Jonathan Bar Or
0 siblings, 0 replies; 23+ messages in thread
From: Jonathan Bar Or @ 2025-02-15 3:17 UTC (permalink / raw)
To: Miquel Raynal
Cc: Tom Rini, Gao Xiang, Huang Jianan, Joao Marcos Costa,
Thomas Petazzoni, u-boot, linux-erofs
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Security vulnerabilities report to Das-U-Boot
2025-02-15 3:17 ` Jonathan Bar Or
@ 2025-02-15 3:24 ` Jonathan Bar Or
-1 siblings, 0 replies; 23+ messages in thread
From: Jonathan Bar Or @ 2025-02-15 3:24 UTC (permalink / raw)
To: Miquel Raynal
Cc: Tom Rini, u-boot, Joao Marcos Costa, Thomas Petazzoni, Gao Xiang,
linux-erofs
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Security vulnerabilities report to Das-U-Boot
@ 2025-02-15 3:24 ` Jonathan Bar Or
0 siblings, 0 replies; 23+ messages in thread
From: Jonathan Bar Or @ 2025-02-15 3:24 UTC (permalink / raw)
To: Miquel Raynal
Cc: Tom Rini, Gao Xiang, Huang Jianan, Joao Marcos Costa,
Thomas Petazzoni, u-boot, linux-erofs
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Security vulnerabilities report to Das-U-Boot
2025-02-15 3:24 ` Jonathan Bar Or
@ 2025-02-22 20:47 ` Jonathan Bar Or
-1 siblings, 0 replies; 23+ messages in thread
From: Jonathan Bar Or @ 2025-02-22 20:47 UTC (permalink / raw)
To: Miquel Raynal
Cc: Tom Rini, u-boot, Joao Marcos Costa, Thomas Petazzoni, Gao Xiang,
linux-erofs
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Security vulnerabilities report to Das-U-Boot
@ 2025-02-22 20:47 ` Jonathan Bar Or
0 siblings, 0 replies; 23+ messages in thread
From: Jonathan Bar Or @ 2025-02-22 20:47 UTC (permalink / raw)
To: Miquel Raynal
Cc: Tom Rini, Gao Xiang, Huang Jianan, Joao Marcos Costa,
Thomas Petazzoni, u-boot, linux-erofs
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Security vulnerabilities report to Das-U-Boot
2025-02-22 20:47 ` Jonathan Bar Or
@ 2025-02-25 17:59 ` Tom Rini
-1 siblings, 0 replies; 23+ messages in thread
From: Tom Rini @ 2025-02-25 17:59 UTC (permalink / raw)
To: Jonathan Bar Or
Cc: u-boot, Joao Marcos Costa, Thomas Petazzoni, Miquel Raynal,
Gao Xiang, linux-erofs
[-- 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 --]
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Security vulnerabilities report to Das-U-Boot
@ 2025-02-25 17:59 ` Tom Rini
0 siblings, 0 replies; 23+ messages in thread
From: Tom Rini @ 2025-02-25 17:59 UTC (permalink / raw)
To: Jonathan Bar Or
Cc: Miquel Raynal, Gao Xiang, Huang Jianan, Joao Marcos Costa,
Thomas Petazzoni, u-boot, linux-erofs
[-- 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 --]
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Security vulnerabilities report to Das-U-Boot
2025-02-25 17:59 ` Tom Rini
@ 2025-02-25 18:18 ` Jonathan Bar Or
-1 siblings, 0 replies; 23+ messages in thread
From: Jonathan Bar Or @ 2025-02-25 18:18 UTC (permalink / raw)
To: Tom Rini
Cc: u-boot, Joao Marcos Costa, Thomas Petazzoni, Miquel Raynal,
Gao Xiang, linux-erofs
[-- Attachment #1: Type: text/plain, Size: 2830 bytes --]
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
>
[-- Attachment #2: Type: text/html, Size: 4186 bytes --]
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Security vulnerabilities report to Das-U-Boot
@ 2025-02-25 18:18 ` Jonathan Bar Or
0 siblings, 0 replies; 23+ messages in thread
From: Jonathan Bar Or @ 2025-02-25 18:18 UTC (permalink / raw)
To: Tom Rini
Cc: Miquel Raynal, Gao Xiang, Huang Jianan, Joao Marcos Costa,
Thomas Petazzoni, u-boot, linux-erofs
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
>
^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2025-02-25 20:43 UTC | newest]
Thread overview: 23+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-02-07 3:47 Security vulnerabilities report to Das-U-Boot Jonathan Bar Or
2025-02-07 15:50 ` Tom Rini
2025-02-07 17:53 ` Jonathan Bar Or
2025-02-10 16:41 ` Tom Rini
2025-02-11 3:51 ` Gao Xiang
2025-02-11 16:26 ` Jonathan Bar Or
2025-02-11 16:26 ` Jonathan Bar Or
2025-02-11 21:29 ` Tom Rini
2025-02-11 21:29 ` Tom Rini
2025-02-11 23:28 ` Jonathan Bar Or
2025-02-11 23:28 ` Jonathan Bar Or
2025-02-12 8:24 ` Miquel Raynal via Linux-erofs
2025-02-12 8:24 ` Miquel Raynal
2025-02-15 3:17 ` Jonathan Bar Or
2025-02-15 3:17 ` Jonathan Bar Or
2025-02-15 3:24 ` Jonathan Bar Or
2025-02-15 3:24 ` Jonathan Bar Or
2025-02-22 20:47 ` Jonathan Bar Or
2025-02-22 20:47 ` Jonathan Bar Or
2025-02-25 17:59 ` Tom Rini
2025-02-25 17:59 ` Tom Rini
2025-02-25 18:18 ` Jonathan Bar Or
2025-02-25 18:18 ` Jonathan Bar Or
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.