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 12:20:09 -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 09:39:12PM +0530, Kiran Kankipati wrote:
> Wow I see. Thanks Greg. I seen the 3.15.2 change logs, found you are involved
> in the LZO issue.
> 
> I read about this issue in some news too that they found 20yr old bug in it.
> 
> So thought reporting to you via email.
> 
> I don't do bugzilla :)
> >> I see.
> 
> I am new to kernel foundation procedures. So sorry for bothering you.
> 
> --------
> Ok, where do you see an overrun happening?  I know the lz4 code in the
> kernel is "old" compared to upstream.  I am working on updating it to
> the latest version, but that's not going to happen until 3.17.
> 
> >> Here is the place and APIs I am using in my TrafficSqueezer code:
> 
> 
> void ts_comp(BYTE *flag, BYTE *pbuff, size_t *pbuff_len, BYTE *mid_buff, BYTE
> *lz4hc_wrkmem)
> {    size_t mid_buff_size = 0;
> 
>     if(lz4hc_compress( (const unsigned char *)pbuff, (*pbuff_len), (unsigned
> char *)mid_buff, &mid_buff_size, (void *)lz4hc_wrkmem)<0) return;
>        
>     if(((mid_buff_size+TS_FLAG_SIZE) < (*pbuff_len)) && (mid_buff_size!=0))
>     {    memcpy((BYTE *)pbuff, (BYTE *)mid_buff, mid_buff_size); (*pbuff_len)=
> mid_buff_size;
>         ts_set_pkt_tag(flag, TS_FLAG_COMP);
>         #ifdef CONFIG_TRAFFICSQUEEZER_DEBUG
>         printk("comp - prossd [LZ4-HC] [mid_buff_size: %zu]\n", mid_buff_size);
>         #endif
>     }
> }
> 
> bool ts_decomp(BYTE *pbuff, size_t *pbuff_len, BYTE *mid_buff)
> {  size_t mid_buff_size = TS_MAX_OPT_BUF_LEN;  //WARNING: DO NOT change this !!
> 
>     if(lz4_decompress_unknownoutputsize( (const unsigned char *)pbuff,
> (*pbuff_len), (unsigned char *)mid_buff,  &mid_buff_size)<0) { return false; }
>     if(mid_buff_size > TS_MAX_OPT_BUF_LEN) { return false; }
>    
>     memcpy((BYTE *)pbuff, (BYTE *)mid_buff, mid_buff_size); (*pbuff_len)=
> mid_buff_size;
> #ifdef CONFIG_TRAFFICSQUEEZER_DEBUG
>     printk("decomp - prossd [LZ4-HC] [mid_buff_size: %zu]\n", mid_buff_size);
> #endif  
>     return true;
> }

I don't understand, are you having problems on the compress side, or the
decompress side?  Where in the lz4 is a bug happening?

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?

> ------------
> If this fix scheduled for 3.17, I am glad enough to wait till then. Since I
> need this fix as a part of mainstream kernel release series :)

The fixes I've done will show up in 3.16-rc3 and in the next round of
stable kernel updates that will come out Monday, so you can pick those
releases up and test if you can't apply individual patches for a kernel
tree.

thanks,

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/