grsecurity forums

Hi Folks,

i have a special Problem with grsec + Kernel 2.6.32.59. I cant compile node.js because the grsecpatch generates a NULL pointer dereference.

Dmesg - Test with Kernel 2.6.32.59 + grsec enabled

PAX: suspicious general protection fault: 0000 [#1] SMP
last sysfs file: /sys/devices/system/cpu/cpu7/cpufreq/stats/time_in_state
Modules linked in: ip6t_rt ip6t_LOG nf_conntrack_ipv6 ip6t_REJECT ip6table_raw ip6table_filter ip6_tables i2c_dev ipt_LOG xt_limit nf_conntrack_ipv4 nf_defrag_ipv4 xt_state xt_multiport xt_NOTRACK iptable_raw ipt_REJECT iptable_filter nf_conntrack_ftp nf_conntrack e1000 e1000e usbcore ipv6

Pid: 7640, comm: node Not tainted (2.6.32.59-grsec #1) To be filled by O.E.M.
EIP: 0060:[<00057a09>] EFLAGS: 00010246 CPU: 0
EAX: 00000007 EBX: 00000007 ECX: bfffef28 EDX: 00000000
ESI: 00000060 EDI: bfffef28 EBP: e3a37f24 ESP: e3a37f08
DS: 0068 ES: 0068 FS: 00d8 GS: 007b SS: 0068
Process node (pid: 7640, ti=e727cc5c task=e727c9c0 task.ti=e727cc5c)
Stack:
00000014 ea7b15d0 e3a37f44 00026951 00000007 00000060 bfffef28 e727cc5c
<0> 00004471 00000007 bfffef28 41425ff4 00000007 bfffef28 bfffef08 00000109
<0> 0000007b bfff007b 00000000 087e0033 00000109 414227e8 00000073 00000246
Call Trace:
[<00026951>] ? do_page_fault+0x171/0x540
[<00004471>] ? syscall_call+0x7/0xb
[<00010246>] ? mce_wrmsrl+0x26/0xc0
[<00010282>] ? mce_wrmsrl+0x62/0xc0
[<00010216>] ? mce_log+0x96/0xa0
[<00010216>] ? mce_log+0x96/0xa0
Code: f8 89 7d fc 85 c0 0f 88 f6 00 00 00 83 f8 0f 0f 87 d5 00 00 00 8b 14 85 60 56 eb c1 85 d2 74 0b 8b 7a 04 85 ff 0f 84 af 00 00 00 <8b> 4a 0c 85 c9 0f 84 e4 00 00 00 8d 7d ec 89 fa ff d1 89 c3 85
EIP: [<00057a09>] sys_clock_gettime+0x39/0x140 SS:ESP 0068:e3a37f08
---[ end trace ebb8184d8c7bc372 ]---

Dmesg - Test with Kernel 2.6.32.59 + grsec patched but grsec disabled

BUG: unable to handle kernel NULL pointer dereference at 0000000c
IP: [<c1054d19>] sys_clock_gettime+0x39/0x140
*pdpt = 0000000029855001 *pde = 0000000000000000
Oops: 0000 [#1] SMP
last sysfs file: /sys/devices/system/cpu/cpu7/cpufreq/stats/time_in_state
Modules linked in: ip6t_rt ip6t_LOG nf_conntrack_ipv6 ip6t_REJECT ip6table_raw ip6table_filter ip6_tables i2c_dev ipt_LOG xt_limit nf_conntrack_ipv4 nf_defrag_ipv4 xt_state xt_multiport xt_NOTRACK iptable_raw ipt_REJECT iptable_filter nf_conntrack_ftp nf_conntrack e1000e usbcore ipv6

Pid: 7528, comm: node Not tainted (2.6.32.59-ohne-grsec #2) To be filled by O.E.M.
EIP: 0060:[<c1054d19>] EFLAGS: 00010246 CPU: 0
EIP is at sys_clock_gettime+0x39/0x140
EAX: 00000007 EBX: 00000007 ECX: bff19708 EDX: 00000000
ESI: 00000007 EDI: bff19708 EBP: e7857fac ESP: e7857f90
DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
Process node (pid: 7528, ti=e9692d1c task=e9692a80 task.ti=e9692d1c)
Stack:
e7857fb4 e7a585bc e9692a80 e7a58588 00000007 00000007 bff19708 e9692d1c
<0> c10032a5 00000007 bff19708 41425ff4 00000007 bff19708 bff196e8 00000109
<0> 0000007b ffff007b c1000000 00000000 00000109 414227e8 00000073 00000246
Call Trace:
[<c10032a5>] ? syscall_call+0x7/0xb
Code: f8 89 7d fc 85 c0 0f 88 f6 00 00 00 83 f8 0f 0f 87 d5 00 00 00 8b 14 85 00 76 65 c1 85 d2 74 0b 8b 7a 04 85 ff 0f 84 af 00 00 00 <8b> 4a 0c 85 c9 0f 84 e4 00 00 00 8d 7d ec 89 fa ff d1 89 c3 85
EIP: [<c1054d19>] sys_clock_gettime+0x39/0x140 SS:ESP 0068:e7857f90
CR2: 000000000000000c
---[ end trace e6395fcedc83fa95 ]---

"paxctl -m" doesnt help

got anybody any hints?

What specific patch was used? I don't see how it's possible with any recent patch.

-Brad

i have used grsecurity-2.9.1-2.6.32.59-201210071703.patch, without this patch there are no problems

have also tried "grsecurity-2.9.1-2.6.32.60-201210121913.patch" with kernel 2.6.32.60 but the problem there still exist

rocknob wrote:have also tried "grsecurity-2.9.1-2.6.32.60-201210121913.patch" with kernel 2.6.32.60 but the problem there still exist

can you send me this oops and the corresponding vmlinux please?

PAX: suspicious general protection fault: 0000 [#1] SMP
last sysfs file: /sys/devices/system/cpu/cpu1/cpufreq/stats/time_in_state
Modules linked in: ip6t_rt ip6t_LOG nf_conntrack_ipv6 ip6t_REJECT ip6table_raw ip6table_filter ip6_tables xt_limit coretemp i2c_dev i2c_i801 ipt_LOG nf_conntrack_ipv4 nf_defrag_ipv4 xt_state xt_multiport xt_NOTRACK iptable_raw ipt_REJECT iptable_filter nf_conntrack_ftp nf_conntrack r8169 usbcore ipv6

Pid: 23569, comm: node Not tainted (2.6.32.60-grsec #1) G31M-ES2L
EIP: 0060:[<00057a19>] EFLAGS: 00010246 CPU: 0
EAX: 00000007 EBX: 00000007 ECX: bdae9128 EDX: 00000000
ESI: 00000060 EDI: bdae9128 EBP: d20aef14 ESP: d20aeef8
DS: 0068 ES: 0068 FS: 00d8 GS: 007b SS: 0068
Process node (pid: 23569, ti=f3aac77c task=f3aac4e0 task.ti=f3aac77c)
Stack:
d20a0000 00000033 ffffffff a53ea770 00000007 00000060 bdae9128 f3aac77c
<0> 00004471 00000007 bdae9128 a53edff4 00000007 bdae9128 bdae9108 00000109
<0> f3aa007b 087d007b 08f70000 00000033 00000109 a53ea7e8 00000073 00000246
Call Trace:
[<00004471>] ? syscall_call+0x7/0xb
[<00010282>] ? mce_wrmsrl+0x32/0xc0
[<0000448c>] ? restore_all+0x0/0x18
[<00010246>] ? mce_log+0x96/0xa0
[<00010212>] ? mce_log+0x62/0xa0
Code: f8 89 7d fc 85 c0 0f 88 f6 00 00 00 83 f8 0f 0f 87 d5 00 00 00 8b 14 85 60 56 eb c1 85 d2 74 0b 8b 7a 04 85 ff 0f 84 af 00 00 00 <8b> 4a 0c 85 c9 0f 84 e4 00 00 00 8d 7d ec 89 fa ff d1 89 c3 85
EIP: [<00057a19>] sys_clock_gettime+0x39/0x140 SS:ESP 0068:d20aeef8
---[ end trace f767898426b528cb ]---

for vmlinux see pm

did you apply any additional patches besides grsec or use some out-of-tree module? thing is, your kernel's sys_clock_gettime was trying to use CLOCK_BOOTTIME that doesn't exist in 2.6.32, and worse, whoever registered that clock type has provided a userland address for its clock_get field, that's not going to fly under KERNEXEC and is a serious security bug on its own.

its a stock kernel, but we use the intel e1000 network modul directly from intel and a RTL8111/8168B PCI Express modul.

edit: have tried to use a new r8168 modul, but problem still occours the intel modul is not in use

edit2: have tried with kernel 2.6.32.25 with grsec patch, there a no problems. .config-file is the same

ok, i figured it out, it seems that grsec's code has diverged from PaX some time ago and a null check got inverted, spender will fix it soon.

perfect! thx !