Messages in this thread | | | Date | Wed, 26 Feb 2020 10:44:08 +0800 | From | Gao Xiang <> | Subject | Re: [PATCH 3/3] erofs: handle corrupted images whose decompressed size less than it'd be |
| |
On Wed, Feb 26, 2020 at 10:40:47AM +0800, Gao Xiang wrote: > Hi Eric, > > On Tue, Feb 25, 2020 at 06:34:58PM -0800, Eric Biggers wrote: > > On Wed, Feb 26, 2020 at 10:30:11AM +0800, Gao Xiang wrote: > > > As Lasse pointed out, "Looking at fs/erofs/decompress.c, > > > the return value from LZ4_decompress_safe_partial is only > > > checked for negative value to catch errors. ... So if > > > I understood it correctly, if there is bad data whose > > > uncompressed size is much less than it should be, it can > > > leave part of the output buffer untouched and expose the > > > previous data as the file content. " > > > > > > Let's fix it now. > > > > > > Cc: Lasse Collin <lasse.collin@tukaani.org> > > > Signed-off-by: Gao Xiang <gaoxiang25@huawei.com> > > > > Shouldn't fixes like this have a Fixes tag and Cc stable? > > > > - Eric > > Thanks for pointing out. *thumb up* > > I reminded Fixes and Cc tags when I sent out. Yet > I'm not quite sure if these have some other potential > concernes which could cause unexpected behavior for > normal images (It seems impossible but not quite sure.) > > I'd like to leave these two commits for corrupted images > to mainline and our products for a while and manually > backport to stable kernels and send them to stable > mailing list later. I keep these fixes in mind all > the time.
... Maybe I should add "Fixes:" tag in the commit message anyway. Will resend them later.
Thanks, Gao Xiang
> > Thanks, > Gao Xiang >
| |