There appears to be some incompatibility when running kernel 2.6.36-hardened-r6 with new SLOB Allocator (CONFIG_SLOB) and with 'Bounds check heap object copies between kernel and userland' (CONFIG_PAX_USERCOPY). Reproducible: Always Steps to Reproduce: Compile 2.6.36-hardened-r6 kernel with CONFIG_SLOB and CONFIG_PAX_USERCOPY and try to boot. Actual Results: Problems with booting, as PAX will be killing programs due to memory leaks. Expected Results: System boots and runs with no errors. As a workaround, use other allocator (SLUB) or disable CONFIG_PAX_USERCOPY.
I just confirmed this and passed the bug upstream. There are newer patches out which I'll be testing too and see if they resolve this issue. Thanks for narrowing it down to SLOB + PAX_USERCOPY.
can you post the PaX logs please (make sure you have KALLSYMS enabled so we get symbols in the backtrace)? also, is .32 affected as well? there're basically no changes in SLOB between 32-36, so i'm surprised we're only getting these reports now...
(In reply to comment #2) > can you post the PaX logs please (make sure you have KALLSYMS enabled so we get > symbols in the backtrace)? also, is .32 affected as well? there're basically no > changes in SLOB between 32-36, so i'm surprised we're only getting these > reports now... > Yes it affects .32 as well. I tested our hardened-sources-2.6.32-r32 which is based on grsecurity-2.2.1-2.6.32.27-201012182005. These are still the latest grsec patches out. I'm working on getting a backtrace, but booting dies in ramdisk when mdev starts. I'll try netconsole.
Created attachment 258293 [details] Full dmesg leading up to a panic Here's just the panic bt: 5.989442] Freeing unused kernel memory: 332k freed [ 6.000785] grsec: mount of proc to /proc by /bin/busybox[mount:478] uid/euid:0/0 gid/egid:0/0, parent /init[init:1] uid/euid:0/0 gid/egid:0/0 [ 10.950267] PAX: kernel memory leak attempt detected from df90cfa8 (6 bytes) [ 10.952264] Pid: 1, comm: switch_root Not tainted 2.6.32-hardened-r32 #1 [ 10.953466] Call Trace: [ 10.954472] [<000965e5>] ? pax_report_leak_to_user+0x48/0x52 [ 10.955620] [<0009effa>] ? filldir64+0x1a2/0x208 [ 10.956729] [<000041ed>] ? per_cpu__runqueues+0xad/0x240 [ 10.957862] [<000a9414>] ? dcache_readdir+0x134/0x189 [ 10.959023] [<0009ee58>] ? filldir64+0x0/0x208 [ 10.960128] [<0009e81a>] ? vfs_readdir+0x62/0x8c [ 10.961229] [<0009ee58>] ? filldir64+0x0/0x208 [ 10.962321] [<0009e90d>] ? sys_getdents64+0xc9/0x133 [ 10.963435] [<00003d86>] ? syscall_call+0x7/0xb [ 10.964588] Kernel panic - not syncing: Attempted to kill init!
I have similar problems with hardened-sources-2.8.38-r6 CONFIG_PAX_USERCOPY=y and CONFIG_SLUB=y (sic) The system boots fine, but when accessing large numbers of files I get this error. Example: # tree /usr results in [61731.719307] PAX: From 192.168.2.21: kernel memory leak attempt detected from e1e8eec0 (jfs_ip) (68 bytes) [61731.719341] Pid: 11770, comm: tree Not tainted 2.6.38-hardened-r6 #3 [61731.719359] Call Trace: [61731.719390] [<0009467e>] ? pax_report_usercopy+0xa1/0xb0 [61731.719419] [<0008d2ed>] ? check_object_size+0x96/0x9c [61731.719449] [<00098c96>] ? vfs_readlink+0xc3/0xef [61731.719479] [<0009a90b>] ? do_path_lookup+0x49/0xd1 [61731.719506] [<00098d51>] ? generic_readlink+0x44/0x68 [61731.719543] [<000932d3>] ? cp_new_stat64+0x149/0x15e [61731.719571] [<000934fa>] ? sys_readlinkat+0x59/0x6a [61731.719599] [<0009351e>] ? sys_readlink+0x13/0x17 [61731.719634] [<00323be5>] ? syscall_call+0x7/0xb [61731.719672] [<000d0890>] ? devpts_remount+0xed/0xf9 [61731.719701] [<00323bfe>] ? restore_all+0x0/0x18 [61731.719728] [<0032007b>] ? w83627ehf_probe+0x488/0x658 are these related?
(In reply to comment #5) > I have similar problems with hardened-sources-2.8.38-r6 CONFIG_PAX_USERCOPY=y > and CONFIG_SLUB=y (sic) > The system boots fine, but when accessing large numbers of files I get this > error. yes, it's another false positive, thanks for reporting. i'll fix it for .32 and .39 (we've moved ahead since ;).
as for the original SLOB/USERCOPY problem, i finally found and fixed at least one bug a few days ago so that now you can boot without problems, however i still managed to produce some reports when i tried to compile stuff, so further investigation is needed. still, i think it's mostly usable now ;).
ping @pageexec: what is the state of SLOB with respect to pax these days? I haven't played with it since this bug was first opened.
i didn't touch it since so 'no idea'. given the general lack of PaX/SLOB users i'm inclined to say to close this one and have people open new bugs if they care.
Reassigned to current maintainer, but can probably be closed.
