I'd like to join the crash party. This size_overflow is not related to the other two reported crashes. It happens quite early during boot. It was the same for 3.19.1-hardened and 3.19.2-hardened. During Easter I had a bit of time to slow down printk to observe the culprit function. Reproducible: Always
can you post your .config? also for the future, enable frame pointers for better backtraces ;).
can you try this patch: --- a/crypto/zlib.c 2015-02-09 21:11:58.221574279 +0100 +++ b/crypto/zlib.c 2015-04-07 00:47:00.694626395 +0200 @@ -95,10 +95,10 @@ zlib_comp_exit(ctx); window_bits = tb[ZLIB_COMP_WINDOWBITS] - ? nla_get_u32(tb[ZLIB_COMP_WINDOWBITS]) + ? nla_get_s32(tb[ZLIB_COMP_WINDOWBITS]) : MAX_WBITS; mem_level = tb[ZLIB_COMP_MEMLEVEL] - ? nla_get_u32(tb[ZLIB_COMP_MEMLEVEL]) + ? nla_get_s32(tb[ZLIB_COMP_MEMLEVEL]) : DEF_MEM_LEVEL; workspacesize = zlib_deflate_workspacesize(window_bits, mem_level);
(In reply to PaX Team from comment #2) > can you try this patch: > > --- a/crypto/zlib.c 2015-02-09 21:11:58.221574279 +0100 > +++ b/crypto/zlib.c 2015-04-07 00:47:00.694626395 +0200 > @@ -95,10 +95,10 @@ > zlib_comp_exit(ctx); > > window_bits = tb[ZLIB_COMP_WINDOWBITS] > - ? > nla_get_u32(tb[ZLIB_COMP_WINDOWBITS]) > + ? > nla_get_s32(tb[ZLIB_COMP_WINDOWBITS]) > : MAX_WBITS; > mem_level = tb[ZLIB_COMP_MEMLEVEL] > - ? nla_get_u32(tb[ZLIB_COMP_MEMLEVEL]) > + ? nla_get_s32(tb[ZLIB_COMP_MEMLEVEL]) > : DEF_MEM_LEVEL; > > workspacesize = zlib_deflate_workspacesize(window_bits, mem_level); This modification solves the size overflow problem!
(In reply to PaX Team from comment #1) > can you post your .config? also for the future, enable frame pointers for > better backtraces ;). I've enabled frame pointers and reverted the modification to make the kernel crash again during boot. Please find the config and the screen captures at the same place I put those previously. Many thanks: Dw
this should have been fixed a while ago, is there still a problem?
I can confirm, that this bug no longer occurs using current version.