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 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