2.6.32.11+ with KERNEXEC and CPU's lacking NX capability

[Grach]

Seems like I have the same issue on my old Athlon XP with the latest 2.6.32.13-grsec-201005151340 patch.

PS
PaX Team, my 64-bit SMP test machine died a few weeks ago, so I even can't say whether the fix you mailed me solves that UDEREF problem.

[jorgus]

Hi there,

grsecurity-2.1.14-2.6.32.14-201005282233.patch is still crashing on our server.

May 31 21:53:26 monster kernel: mysqld: Corrupted page table at address 7ff18004
May 31 21:53:26 monster kernel: *pdpt = 000000000dd71001 *pde = 0062642f6c717379
May 31 21:53:26 monster kernel: Bad pagetable: 000f [#1] SMP
May 31 21:53:26 monster kernel: last sysfs file: /sys/class/net/lo/operstate
May 31 21:53:26 monster kernel: Modules linked in: ipt_REJECT tun bitrev crc32 ipt_LOG xt_tcpudp xt_state iptable_filter iptable_mangle iptable_raw iptable_nat nf_nat ip_tables x_tables nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 hangcheck_timer iTCO_wdt iTCO_vendor_support w83781d hwmon_vid hwmon e1000 i5000_edac i2c_i801 i2c_core edac_core ioatdma dca button processor sg arcmsr e1000e thermal thermal_sys [last unloaded: scsi_wait_scan]
May 31 21:53:26 monster kernel:
May 31 21:53:26 monster kernel: Pid: 19472, comm: mysqld Not tainted (2.6.32.14-gs-probe3 #1) empty
May 31 21:53:26 monster kernel: EIP: 0073:[<b7bada11>] EFLAGS: 00210202 CPU: 0
May 31 21:53:26 monster kernel: EAX: 0017d002 EBX: b7c92ff4 ECX: 0017d000 EDX: 7ff18000
May 31 21:53:26 monster kernel: ESI: 0017d000 EDI: 37ff0fff EBP: 862654e4 ESP: 86265434
May 31 21:53:26 monster kernel: DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b
May 31 21:53:26 monster kernel: Process mysqld (pid: 19472, ti=c7946000 task=f6e00180 task.ti=c7946000)
May 31 21:53:26 monster kernel:
May 31 21:53:26 monster kernel: EIP: [<b7bada11>] SS:ESP 007b:86265434
May 31 21:53:26 monster kernel: ---[ end trace f96021cfb3929deb ]---

I'm not sure if this is of any relevance, but on the particular machine that is crashing after a day or two out of a few machines working pretty fine otherwise there is

kernel.randomize_va_space = 0

in /etc/sysctl.conf. I'm about to recompile 2.6.32.14 without this PGD which helped for 2.6.32.13. The CPU definitely has NX capability as well.

processor : 7
vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel(R) Xeon(R) CPU E5335 @ 2.00GHz
stepping : 11
cpu MHz : 1995.321
cache size : 4096 KB
physical id : 1
siblings : 4
core id : 3
cpu cores : 4
apicid : 7
initial apicid : 7
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl vmx tm2 ssse3 cx16 xtpr pdcm dca lahf_lm tpr_shadow vnmi flexpriority
bogomips : 3990.06
clflush size : 64
cache_alignment : 64
address sizes : 38 bits physical, 48 bits virtual
power management:

[PaX Team]

can you guys test the last PaX test patches please? i hope resolved all known issues with the per-CPU PGD code, including the page table corruption and memory leak on PARAVIRT.

[jorgus]

Unfortunately we need a full grsec patch to test it. But I see one was released yesterday. Does grsecurity-2.2.0-2.6.32.15-201006192153.patch include the latest PAX version you would like to be tested?

[PaX Team]

Does grsecurity-2.2.0-2.6.32.15-201006192153.patch include the latest PAX version you would like to be tested?

yes, it's pretty much always based on the last PaX patch.

[spender]

I uploaded two new patches yesterday, one a "2.1.14" version, and one "2.2.0" version. Both contain the latest PaX code. The only difference between the two patches are the addition of capability auditing and log suppression in the RBAC system, and a new option for distros to allow the privileged i/o option to be toggled via sysctl.

-Brad

[jorgus]

Hi,

I gave 2.6.32.15 + grsecurity-2.1.14-2.6.32.15-201006191115.patch a try on my production server experiencing PGD kernel panics before. Unfortunately I've just remembered that on this server kernel.randomize_va_space is not 0 anymore (I agreed with my boss to turn it back on). As far as I remember all PGD crashes we experienced were with kernel.randomize_va_space=0, if that's of any relevance. I point this out because this was our only server with randomization disabled and the only one out of 8 experiencing PGD crashes (coincidence or something more?).
So, sorry if in the end I give you a false sense of the patch resolving the problem