linux-kernel - Re: Bug in Kernel's LZ4-HC in 64bit (kernel crypto library)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:	Sat, 28 Jun 2014 13:36:36 -0400
From:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:	Kiran Kankipati <kiran.kankipati@...il.com>
Cc:	"Don A. Bailey" <donb@...uritymouse.com>,
	linux-kernel@...r.kernel.org
Subject: Re: Bug in Kernel's LZ4-HC in 64bit (kernel crypto library)

On Sat, Jun 28, 2014 at 10:02:19PM +0530, Kiran Kankipati wrote:
> I don't understand, are you having problems on the compress side, or the
> decompress side?  Where in the lz4 is a bug happening?
> >> Sorry sorry.
> I dont have a clue. Well the reason is, if compress is happening well and
> decomp is getting this issue. Then decomp is having a bug.
> If compression is corrupting data, then decomp may get this issue too. Hence I
> am not fully sure.
> But the error code happening in the decomp API.
> 
> 
> Do you have a data stream that I can use to run it through the lz4 code
> to see where the problem is in the compress/decompress code?
> >> Again sorry about it. Since  iam testing with real-time packets. I dont have
> it Greg.
> 
> I can copypaste the error logs of my TrafficSqueezer per-packet tests. Since  I
> am running a simulation test, I am doing each packet
> compression + decompression. This way I can test TrafficSqueezer stack. As well
> in our case we can test LZ4 too.
> 
> Kindly refer screenshot:
> 
> But please note, sometimes it works fine too. Sometimes I am getting this error
> :(
> 
> Its purely LZ4-HC error. Since the return code of
> lz4_decompress_unknownoutputsize() API is <0 i.e error !

As you are compressing and then decompressing, this doesn't look to be
the same "type" of error we have fixed recently, so I don't know what to
do here.

If you find a data stream that this can be tested with, please let me
know and I'll be glad to try it out.  Until then, I need more of a hint
as to the problem before I can do anything, sorry.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/