This bug is new in 4.2.6-r6. Version 4.2.6-r5 is not affected. Decompress of initramfs crash with this error: Unpacking initramfs...^M PAX: size overflow detected in function get_bits lib/decompress_bunzip2.c:143 cicus.147_113 max, count: 19, decl: inbufBits; num: 0; cont ext: bunzip_data;^M CPU: 2 PID: 1 Comm: swapper/0 Not tainted 4.2.6-hardened-r6 #1^M Hardware name: To be filled by O.E.M. To be filled by O.E.M./M5A99FX PRO R2.0, BIOS 2501 04/07/2014^M ffffffff8186d72b 62cd2da4758f95c8 0000000000000000 ffffffff8166059d^M ffffffff8186d722 ffffffff811756b5 ffff88084eff9d80 ffff88082a1b0000^M 0000000000000000 ffffffff81c15418 0000000000000018 ffffffff81c4b476^M Call Trace:^M [<ffffffff8166059d>] ? dump_stack+0x40/0x54^M [<ffffffff811756b5>] ? report_size_overflow+0x35/0x40^M [<ffffffff81c15418>] ? write_buffer+0x62/0x10e^M [<ffffffff81c4b476>] ? get_bits+0x283/0x417^M [<ffffffff81c154c4>] ? write_buffer+0x10e/0x10e^M [<ffffffff81c4b654>] ? get_next_block+0x4a/0xe2f^M [<ffffffff8113b3d7>] ? __pte_alloc_kernel+0x37/0xd0^M [<ffffffff8114e15e>] ? vmap_page_range_noflush+0x2be/0x370^M [<ffffffff8114e651>] ? map_vm_area+0x41/0x70^M [<ffffffff8114fa74>] ? __vmalloc_node_range+0x274/0x3b0^M [<ffffffff81c4c6e6>] ? bunzip2+0x289/0x784^M [<ffffffff81c154c4>] ? write_buffer+0x10e/0x10e^M [<ffffffff8114fe96>] ? vmalloc+0x56/0x60^M [<ffffffff81c154c4>] ? write_buffer+0x10e/0x10e^M [<ffffffff81c4c8fc>] ? bunzip2+0x49f/0x784^M [<ffffffff81c15f6b>] ? unpack_to_rootfs+0x228/0x466^M [<ffffffff81c15203>] ? md_run_setup+0xcb/0xcb^M [<ffffffff81c16856>] ? populate_rootfs+0xbe/0x159^M [<ffffffff81c16798>] ? do_header+0x2d5/0x2d5^M [<ffffffff810004a7>] ? do_one_initcall+0x87/0x190^M [<ffffffff81c13ab7>] ? kernel_init_freeable+0x173/0x267^M [<ffffffff8165a290>] ? rest_init+0x80/0x80^M [<ffffffff8165a299>] ? kernel_init+0x9/0xe0^M [<ffffffff81666b79>] ? ret_from_fork+0x39/0x60^M [<ffffffff8165a290>] ? rest_init+0x80/0x80^M Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009^M
could you print out the values of bd->inbufBits and bd->inbufPos before line 143 like this: printk("PAX: bd->inbufBits:%x bd->inbufPos:%lx\n", bd->inbufBits, bd->inbufPos);
PAX: bd->inbufBits:0 bd->inbufPos:0 PAX: bd->inbufBits:42 bd->inbufPos:1 PAX: bd->inbufBits:425a bd->inbufPos:2 PAX: bd->inbufBits:425a68 bd->inbufPos:3 PAX: bd->inbufBits:425a6839 bd->inbufPos:4
hmm, it looks like some code is trying to extract more than 32 bits but this function cannot return that many. can you also add bits_wanted and bd->inbufBitCount to the printk to see if that's really the case?
here's a discussion thread on the btrfs list: http://marc.info/?t=144862133900003&r=1&w=2 , perhaps you can try the proposed patch too (though i'm not sure if it's the right fix as it merely avoids triggering the overflow but otherwise doesn't touch the merge logic).
I added printk("PAX: bd->inbufBits:%x bd->inbufPos:%lx bd->inbufBitCount%x\n", bd->inbufBits,bd->inbufPos,bd->inbufBitCount); And there is result: Unpacking initramfs... PAX: bd->inbufBits:0 bd->inbufPos:0 bd->inbufBitCount0 PAX: bd->inbufBits:42 bd->inbufPos:1 bd->inbufBitCount8 PAX: bd->inbufBits:425a bd->inbufPos:2 bd->inbufBitCount10 PAX: bd->inbufBits:425a68 bd->inbufPos:3 bd->inbufBitCount0 PAX: bd->inbufBits:425a6839 bd->inbufPos:4 bd->inbufBitCount0 PAX: size overflow detected in function get_bits lib/decompress_bunzip2.c:144 ci cus.151_117 max, count: 19, decl: inbufBits; num: 0; context: bunzip_data; CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.2.6-hardened-r6 #3
(In reply to PaX Team from comment #4) > here's a discussion thread on the btrfs list: > http://marc.info/?t=144862133900003&r=1&w=2 , perhaps you can try the > proposed patch too (though i'm not sure if it's the right fix as it merely > avoids triggering the overflow but otherwise doesn't touch the merge logic). oops, wrong bug, ignore me ;).
can you also print out bits_wanted?
Sorry, I missed bits_wanted. There is output of printk("PAX: bd->inbufBits:%x bd->inbufPos:%lx bd->inbufBitCount%x, bits_wanted:%x\n", bd->inbufBits,bd->inbufPos,bd->inbufBitCount,bits_wanted); Unpacking initramfs... PAX: bd->inbufBits:0 bd->inbufPos:0 bd->inbufBitCount0, bits_wanted:20 PAX: bd->inbufBits:42 bd->inbufPos:1 bd->inbufBitCount8, bits_wanted:20 PAX: bd->inbufBits:425a bd->inbufPos:2 bd->inbufBitCount10, bits_wanted:20 PAX: bd->inbufBits:425a68 bd->inbufPos:3 bd->inbufBitCount0, bits_wanted:8 PAX: bd->inbufBits:425a6839 bd->inbufPos:4 bd->inbufBitCount0, bits_wanted:18 PAX: size overflow detected in function get_bits lib/decompress_bunzip2.c:144 ci cus.151_118 max, count: 19, decl: inbufBits; num: 0; context: bunzip_data; CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.2.6-hardened-r6 #5
The sequence of computation you're seeing shouldn't be possible -- the last iteration of the loop shouldn't be happening, but is happening for some reason unexplained by the values being printed. Can you provide your config and gcc version? Are you using any additional compiler flags we should be aware of? If possible, could you also provide me with the decompress_bunzip2.o file from your built kernel source? Thanks, -Brad
gcc --version gcc (Gentoo Hardened 4.9.3 p1.2, pie-0.6.3) 4.9.3 use flags: Installed versions: 4.9.3(4.9)^s(17:32:08 02.10.2015)(cxx hardened nls nptl op enmp -altivec -awt -cilk -debug -doc -fixed-point -fortran -gcj -go -graphite -l ibssp -multilib -multislot -nopie -nossp -objc -objc++ -objc-gc -regression-test -sanitize -vanilla) From make.conf: CFLAGS="${CFLAGS} -march=bdver2 -mtune=bdver2 -mfpmath=sse -O2 -pipe" LDFLAGS="${LDFLAGS} -Wl,--hash-style=gnu" CXXFLAGS="${CFLAGS}" .config and decompress_bunzip2.o are in attachment
Created attachment 418148 [details] .config
Created attachment 418150 [details] decompress_bunzip.o
Could you please send me the results (lib/decompress_bunzip2.*) of make lib/decompress_bunzip2.o EXTRA_CFLAGS="-fdump-tree-all -fdump-ipa-all", make lib/decompress_bunzip2.s and your vmlinux, bzImage?
Created attachment 418234 [details] result of EXTRA_CFLAGS="-fdump-tree-all -fdumo-ipa-all" make lib/decompress_bunzip2.o
Created attachment 418236 [details] decompress_bunzip2.s
Result of EXTRA_CFLAGS="-fdump-tree-all -fdumo-ipa-all" make lib/decompress_bunzip2.o EXTRA_CFLAGS="-fdump-tree-all -fdumo-ipa-all" make lib/decompress_bunzip2.s are in attachment. How can I send bzImage vmlinux to you? Will be useful try boot this kernel? Buggy kernel has been compiled by make -j8 bzImage modules.
I need all gcc dump files (lib/decompress_bunzip2.*). Could you please run this command (use EXTRA_CFLAGS after make) and send me the files? :): make lib/decompress_bunzip2.o EXTRA_CFLAGS="-fdump-tree-all -fdump-ipa-all"
(In reply to Martin Filo from comment #16) > How can I send bzImage vmlinux to you? > Will be useful try boot this kernel? > Buggy kernel has been compiled by make -j8 bzImage modules. Yes, I'd boot your kernel (bzImage) and debug vmlinux with gdb. Please enable these options as well: CONFIG_DEBUG_INFO CONFIG_FRAME_POINTER
After make clean, I added CONFIG_DEBUG_INFO CONFIG_FRAME_POINTER, compiled this with make bzImage modules modules_install. I tested that it crashes the same way. I ran make lib/decompress_bunzip2.o EXTRA_CFLAGS="-fdump-tree-all -fdump-ipa-all" I will send decompress_bunzip2.*, bzImage and vmlinux to you via email because they are too large to add them here.
I can't boot your image, some kernel config options are missing. Could you please enable these options too: CONFIG_VIRTIO_BLK=y CONFIG_SCSI_VIRTIO=y CONFIG_HW_RANDOM_VIRTIO=y CONFIG_VIRTIO=y CONFIG_VIRTIO_PCI=y CONFIG_VIRTIO_PCI_LEGACY=y CONFIG_VIRTIO_BALLOON=y CONFIG_VIRTIO_INPUT=y CONFIG_VIRTIO_MMIO=y CONFIG_VIRTIO_MMIO_CMDLINE_DEVICES=y and send me the previous files (include your initramfs).
I enabled options, which you mentioned. I reproduced crash with this kernel and this test initram in qemu. Files are there: http://uloz.to/xVk9MhJt/debug-tar-xz-gpg deletion link: http://uloz.to/smazat/xVk9MhJt/4123002014808367616 Password the same as previously.
(In reply to Martin Filo from comment #0) > This bug is new in 4.2.6-r6. > > PAX: size overflow detected in function get_bits > lib/decompress_bunzip2.c:143 cicus.147_113 max, count: 19, decl: inbufBits; > num: 0; cont Did you reproduce it with grsec version 4.3.3?
Yes, I tried 4.3.3-r1 with same result.
(In reply to Martin Filo from comment #23) > Yes, I tried 4.3.3-r1 with same result. I just added 4.3.3-r2 to the tree. I'm punting -r1.
Version 4.3.3-r2 is affected too.
(In reply to Martin Filo from comment #25) > Version 4.3.3-r2 is affected too. can you check 4.3.3-r4 please. its our next stabilization candidate.
Kernel bunzip2 still crashing, but xz work fine. I'm using xz instead of bz2. I have nothing against stabilization of 4.3.3-r4.
(In reply to Martin Filo from comment #27) > Kernel bunzip2 still crashing, but xz work fine. I'm using xz instead of > bz2. I have nothing against stabilization of 4.3.3-r4. Thanks for the report, it will be fixed in the next grsec patch.
(In reply to Emese Revfy from comment #28) > (In reply to Martin Filo from comment #27) > > Kernel bunzip2 still crashing, but xz work fine. I'm using xz instead of > > bz2. I have nothing against stabilization of 4.3.3-r4. > > Thanks for the report, it will be fixed in the next grsec patch. Okay this has been fixed for a while.
