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

[Greg Kroah-Hartman]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/