grsecurity forums

2.4.31-grsec on RHEL3
above commands return Segmentation fault
gradm disabled
Here is my kernel config http://forums.grsecurity.net/viewtopic.php?t=1304
Found nothing in system logs.

Code: Select all

ltrace dig
__libc_start_main(0x804d7c0, 1, 0xbffffa44, 0x8053aec, 0x8053b34 <unfinished ...>
isc_app_start(1, 0xbffffa44, 0x8053b34, 0x4039e898, 0x4039e898)                                                        = 0
isc_net_probeipv4(0x805521d, 0, 0, 0, 0xbffffa44)                                                                      = 0
isc_net_probeipv6(0x805521d, 0, 0, 0, 0xbffffa44)                                                                      = 23
isc_mem_create(0, 0, 0x8057508, 0, 0xbffffa44)                                                                         = 0
isc_taskmgr_create(0x8058a70, 1, 0, 0x805750c, 0xbffffa44 <unfinished ...>
--- SIGSEGV (Segmentation fault) ---
+++ killed by SIGSEGV +++

What other kernels have you run on the system that don't produce the crashing problem? Have you tried a vanilla, non-RHEL kernel?

-Brad

if I understand you well this is vanilla kernel.
Latest kernel from kernel.org with rhel .config
I haven't try any other kernels and configuration.

bartosz wrote:2.4.31-grsec on RHEL3
above commands return Segmentation fault
gradm disabled
Here is my kernel config http://forums.grsecurity.net/viewtopic.php?t=1304
Found nothing in system logs.

enable coredumping then analyze the core, i posted instructions on the forum and the mailing list as well.

you mean comment out the call to no_coredump() in gradm?
I just want to be sure because segfault happens when gradm is disabled

bartosz wrote:you mean comment out the call to no_coredump() in gradm?
I just want to be sure because segfault happens when gradm is disabled

no, i meant ulimit -c unlimited in your shell, then run dig/etc to produce a coredump.

Code: Select all

Core was generated by `dig'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/lib/libdns.so.16...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libdns.so.16
Reading symbols from /usr/lib/libisc.so.7...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libisc.so.7
Reading symbols from /lib/libcrypto.so.4...(no debugging symbols found)...done.
Loaded symbols for /lib/libcrypto.so.4
Reading symbols from /lib/libnsl.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/libnsl.so.1
Reading symbols from /lib/tls/libpthread.so.0...(no debugging symbols found)...done.
Loaded symbols for /lib/tls/libpthread.so.0
Reading symbols from /lib/tls/libc.so.6...
(no debugging symbols found)...done.
Loaded symbols for /lib/tls/libc.so.6
Reading symbols from /usr/kerberos/lib/libgssapi_krb5.so.2...(no debugging symbols found)...done.
Loaded symbols for /usr/kerberos/lib/libgssapi_krb5.so.2
Reading symbols from /usr/kerberos/lib/libkrb5.so.3...(no debugging symbols found)...done.
Loaded symbols for /usr/kerberos/lib/libkrb5.so.3
Reading symbols from /usr/kerberos/lib/libcom_err.so.3...(no debugging symbols found)...done.
Loaded symbols for /usr/kerberos/lib/libcom_err.so.3
Reading symbols from /usr/kerberos/lib/libk5crypto.so.3...(no debugging symbols found)...done.
Loaded symbols for /usr/kerberos/lib/libk5crypto.so.3
Reading symbols from /lib/libresolv.so.2...
(no debugging symbols found)...done.
Loaded symbols for /lib/libresolv.so.2
Reading symbols from /lib/libdl.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /usr/lib/libz.so.1...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libz.so.1
Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/ld-linux.so.2
#0  0x00000000 in ?? ()
(gdb) bt
#0  0x00000000 in ?? ()
#1  0x4025ede8 in start_thread () from /lib/tls/libpthread.so.0
#2  0x4034693a in clone () from /lib/tls/libc.so.6
(gdb) info reg
eax            0x0      0
ecx            0x4025edc9       1076227529
edx            0x40c4dac0       1086642880
ebx            0x40267b5c       1076263772
esp            0x40c4da8c       0x40c4da8c
ebp            0x40c4db08       0x40c4db08
esi            0x40c4dbb0       1086643120
edi            0x40c4dac0       1086642880
eip            0x0      0x0
eflags         0x10246  66118
cs             0x23     35
ss             0x2b     43
ds             0x2b     43
es             0x2b     43
fs             0x2b     43
gs             0x2b     43

this is something new for me
what additional comands shoud I run in gdb to help you to help me ?

bartosz wrote:

Code: Select all

Loaded symbols for /lib/ld-linux.so.2
#0  0x00000000 in ?? ()
(gdb) bt
#0  0x00000000 in ?? ()
#1  0x4025ede8 in start_thread () from /lib/tls/libpthread.so.0
#2  0x4034693a in clone () from /lib/tls/libc.so.6
(gdb) info reg
eax            0x0      0
ecx            0x4025edc9       1076227529
edx            0x40c4dac0       1086642880
ebx            0x40267b5c       1076263772
esp            0x40c4da8c       0x40c4da8c
ebp            0x40c4db08       0x40c4db08
esi            0x40c4dbb0       1086643120
edi            0x40c4dac0       1086642880
eip            0x0      0x0
eflags         0x10246  66118
cs             0x23     35
ss             0x2b     43
ds             0x2b     43
es             0x2b     43
fs             0x2b     43
gs             0x2b     43

this is something new for me
what additional comands shoud I run in gdb to help you to help me ?

hmm, interesting. on one hand, you're using the NPTL glibc, on the other hand i don't see the thread specific data area set up (gs register), so that would explain why things crash with threads. you could do a x/16x $sp to dump the stack and also x/100i start_thread to look at the disasm a bit. you can also try to set LD_ASSUME_KERNEL to something like 2.4.1 and see if that helps (that should switch to the old linuxthreads glibc).

LD_ASSUME_KERNEL=2.4.1
works fine
thanks for help