grsecurity forums

3.2.37 with matching grsecurity
all grsecurity and pax options are enabled - maximum security.
Debian stable (6.0) running in VM - KVM.

[(time).760338] PAX: From 192.168.(lan gateway ip): execution attempt in: (null), 00000000-00000000 00000000
[(time).797854] PAX: terminating task: /usr/bin/php5(php):8026, uid/euid: 33/33, PC: 000072cadcfefa90, SP: 00007a63920c7458
[(time).802515] PAX: bytes at PC: ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
[(time).807691] PAX: bytes at SP-8: 0000000000000060 000072cae49b557f 00000000000000ee 000072cae3c55a29 000000000000020f 000072cae3c6aa72 00000000000000ab 000072cae3c5e2a5 0000000000000000 000072cae3e90769 0000000000000000

What can be deduced about the problem from this information?

How could I get all the information and analyze it (core?) to find out what programming error in php5 binary lead to this (trying to derefrence null?)

if you can reproduce this by disabling PaX on the php binary then you can just use gdb to debug this and look at the crashing code there. otherwise you'll have to enable coredumps for php (in the parent process or shell probably) and look at the coredump (disabling ASLR will make it easier to correlate addresses). by the look of it the to-be-executed code looks like an almost valid pointer, probably the result of some bad pointer arithmetic. based on the stack dump the caller was probably at 000072cae49b557f so you should figure out what is mapped there (again, disabling ASLR will make this much easier). you can also try to strace php and see if there're any suspicious mmap/mprotect requests that fail, mishandling those can result in all kinds of fun side effects.