From: Greg KH <gregkh@linuxfoundation.org>
To: Krzysztof Kolasa <kkolasa@winsoft.pl>
Cc: dsterba@suse.cz, tom.yeon@windriver.com, linux-kernel@vger.kernel.org
Subject: Re: lz4: fix system halted at boot kernel x86_64 compressed lz4
Date: Fri, 3 Apr 2015 15:17:31 +0200 [thread overview]
Message-ID: <20150403131731.GA28380@kroah.com> (raw)
In-Reply-To: <551E7AA2.1050206@winsoft.pl>
On Fri, Apr 03, 2015 at 01:33:54PM +0200, Krzysztof Kolasa wrote:
> On 31.03.2015 17:22, Greg KH wrote:
> > On Wed, Mar 25, 2015 at 08:04:59AM +0100, Krzysztof Kolasa wrote:
> >> On 25.03.2015 01:44, David Sterba wrote:
> >>> On Tue, Mar 24, 2015 at 12:27:25PM +0100, Krzysztof Kolasa wrote:
> >>>> lz4: fix system halted at boot kernel x86_64 compressed lz4
> >>>>
> >>>> Decompression process ends with an error when loading kernel:
> >>>>
> >>>> Decoding failed
> >>>> -- System halted
> >>> Serious regression detected ...
> >>>
> >>>> This condition is probably not needed ( from the last commit d5e7caf) :
> >>> The offending patch is on the way to stable trees, so it would be best
> >>> to postpone it for now.
> >>>
> >>>> if( ... ||
> >>>> (op + COPYLENGTH) > oend)
> >>>> goto _output_error
> >>>>
> >>>> macro LZ4_SECURE_COPY() tests op and does not copy any data
> >>>> when op exceeds the value, decompression process is continued.
> >>>>
> >>>> added by analogy security for the ref:
> >>>>
> >>>> if ((ref + COPYLENGTH) > oend...
> >>>>
> >>>> to lz4_uncompress_unknownoutputsize(...)
> >>> I did only a quick check, your analysis seems correct. Reviewing the lz4
> >>> patches is tedious as the kernel implementations do not match the
> >>> upstream one line-by-line besides that I've missed the side effects of
> >>> the macro.
> >>>
> >> Add patch source for review (send to LKML) :
> >> ---------------------
> >>
> >> lz4: fix system halted at boot kernel x86_64 compressed lz4
> >>
> >> Decompression process ends with an error when loading kernel:
> >>
> >> Decoding failed
> >> -- System halted
> >>
> >> This condition is probably not needed ( from the last commit d5e7caf) :
> >>
> >> if( ... ||
> >> (op + COPYLENGTH) > oend)
> >> goto _output_error
> >>
> >> macro LZ4_SECURE_COPY() tests op and does not copy any data
> >> when op exceeds the value, decompression process is continued.
> >>
> >> added by analogy security for the ref:
> >>
> >> if ((ref + COPYLENGTH) > oend...
> >>
> >> to lz4_uncompress_unknownoutputsize(...)
> >>
> >> Signed-off-by: Krzysztof Kolasa <kkolasa@winsoft.pl>
> >> ---
> >> lib/lz4/lz4_decompress.c | 5 +++--
> >> 1 file changed, 3 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/lib/lz4/lz4_decompress.c b/lib/lz4/lz4_decompress.c
> >> index f0f5c5c..e248c4e 100644
> >> --- a/lib/lz4/lz4_decompress.c
> >> +++ b/lib/lz4/lz4_decompress.c
> >> @@ -139,8 +139,7 @@ static int lz4_uncompress(const char *source, char *dest, int osize)
> >> /* Error: request to write beyond destination buffer */
> >> if (cpy > oend)
> >> goto _output_error;
> >> - if ((ref + COPYLENGTH) > oend ||
> >> - (op + COPYLENGTH) > oend)
> >> + if ((ref + COPYLENGTH) > oend)
> >> goto _output_error;
> >> LZ4_SECURECOPY(ref, op, (oend - COPYLENGTH));
> >> while (op < cpy)
> >> @@ -270,6 +269,8 @@ static int lz4_uncompress_unknownoutputsize(const char *source, char *dest,
> >> if (cpy > oend - COPYLENGTH) {
> >> if (cpy > oend)
> >> goto _output_error; /* write outside of buf */
> >> + if ((ref + COPYLENGTH) > oend)
> >> + goto _output_error;
> >>
> >> LZ4_SECURECOPY(ref, op, (oend - COPYLENGTH));
> >> while (op < cpy)
> >> -- 2.3.3.dirty
> > I'm confused, what is the problem here? What went wrong with the
> x86_64 lz4 kernel halted system...
> > original patch that was posted, which is a mirror of what the lz4 code
> > looks like "upstream"?
> >
> > Why make this change? Does it need to go into 4.0-final, or should I
> > just revert the original patch?
> >
> > confused,
> >
> > greg k-h
> >
> OK, after further tests have modified the previous patch, please check and analyze:
What "previous patch"? None of my questions were answered here, so I
have no idea what is going on at all.
I'm going to have to just revert the original patch as obviously
something is wrong, but no one will tell me what, so I'll just go back
to the old behavior...
thanks,
greg k-h
next prev parent reply other threads:[~2015-04-03 13:17 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <55114A1D.7030508@winsoft.pl>
2015-03-25 0:44 ` lz4: fix system halted at boot kernel x86_64 compressed lz4 David Sterba
2015-03-25 7:04 ` Krzysztof Kolasa
2015-03-31 15:22 ` Greg KH
2015-04-03 11:33 ` Krzysztof Kolasa
2015-04-03 13:17 ` Greg KH [this message]
2015-04-03 13:58 ` Krzysztof Kolasa
2015-04-03 14:17 ` Alexander Kuleshov
2015-04-03 14:23 ` Greg KH
2015-04-03 14:30 ` Krzysztof Kolasa
2015-04-03 14:44 ` Greg KH
2015-04-03 15:12 ` [PATCHv2] " Krzysztof Kolasa
2015-04-03 17:36 ` Greg KH
2015-04-03 18:03 ` Krzysztof Kolasa
2015-04-03 18:06 ` Greg KH
2015-04-03 18:18 ` Alexander Kuleshov
2015-04-03 19:01 ` Greg KH
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150403131731.GA28380@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=dsterba@suse.cz \
--cc=kkolasa@winsoft.pl \
--cc=linux-kernel@vger.kernel.org \
--cc=tom.yeon@windriver.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox