On Mon, May 30, 2022 at 08:11:26AM +0200, Stefan Roese wrote:
> Added Tom to Cc...
>
> On 23.05.22 11:25, Pali Rohár wrote:
> > On Thursday 19 May 2022 10:04:31 Pali Rohár wrote:
> > > On Thursday 19 May 2022 07:01:19 Stefan Roese wrote:
> > > > On 17.05.22 22:45, Pali Rohár wrote:
> > > > > Commit b1a14f8a1c2e ("UBIFS: Change ubifsload to not read beyond the
> > > > > requested size") added optimization to do not read more bytes than it
> > > > > is
> > > > > really needed. But this commit introduced incorrect handling of the
> > > > > hole at
> > > > > the end of file. This logic cause U-Boot to crash or lockup when
> > > > > trying to
> > > > > read from the ubifs filesystem.
> > > > >
> > > > > When read_block() call returns -ENOENT error (not an error, but the
> > > > > hole)
> > > > > then dn-> structure is not filled and contain garbage. So using of
> > > > > dn->size
> > > > > for memcpy() argument cause that U-Boot tries to copy unspecified
> > > > > amount of
> > > > > bytes from possible unmapped memory. Which randomly cause lockup of
> > > > > P2020
> > > > > CPU.
> > > > >
> > > > > Fix this issue by copying UBIFS_BLOCK_SIZE bytes from read buffer when
> > > > > dn->size is not available. UBIFS_BLOCK_SIZE is the size of the buffer
> > > > > itself and read_block() fills buffer by zeros when it returns -ENOENT.
> > > > >
> > > > > This patch fixes ubifsload on P2020.
> > > > >
> > > > > Fixes: b1a14f8a1c2e ("UBIFS: Change ubifsload to not read beyond the
> > > > > requested size")
> > > > > Signed-off-by: Pali Rohár <p...@kernel.org>
> > > >
> > > > Reviewed-by: Stefan Roese <s...@denx.de>
> >
> > Anyway, who is maintainer of fs / ubifs code and can take this bugfix patch?
>
> Tom, could you please pick this patch up? I've seen that you've already
> assigned it to yourself in patchwork:
>
> http://patchwork.ozlabs.org/project/uboot/patch/20220517204528.7277-1-p...@kernel.org/I've put it in my queue, thanks. -- Tom
signature.asc
Description: PGP signature
