Security vulnerabilities report to Das-U-Boot

[Tom Rini]

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 at 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 at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/linux-erofs/attachments/20250211/e026ee76/attachment.sig>