GDB backtrace corrupt even after -permsx with chpax/paxctl

[Razathorn]

As the topic states -- any generated core files, attaching to the process, or even running the process under gdb, generates corrupt stack backtraces.

The system is 2.4.29 with grsecurity-2.1.3-2.4.29-200503070900.patch. The new header marking system is enabled, the old is disabled. This is a debian stable system.

# ./paxctl -v ./sleep
PaX control v0.3
Copyright 2004,2005 PaX Team <pageexec@freemail.hu>

- PaX flags: -p-s-m-x-e-r [./sleep]
PAGEEXEC is disabled
SEGMEXEC is disabled
MPROTECT is disabled
RANDEXEC is disabled
EMUTRAMP is disabled
RANDMMAP is disabled
# ./paxctl -v ./gdb
PaX control v0.3
Copyright 2004,2005 PaX Team <pageexec@freemail.hu>

- PaX flags: -p-s-m-x-e-r [./gdb]
PAGEEXEC is disabled
SEGMEXEC is disabled
MPROTECT is disabled
RANDEXEC is disabled
EMUTRAMP is disabled
RANDMMAP is disabled
# ./gdb ./sleep
GNU gdb 6.3-debian
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-linux"...(no debugging symbols found)
Using host libthread_db library "/lib/libthread_db.so.1".

(gdb) set args 500
(gdb) run
Starting program: /root/raz/test/sleep 500
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 296)]

Program received signal SIGINT, Interrupt.
[Switching to Thread 16384 (LWP 296)]
0x400fad95 in nanosleep () from /lib/libc.so.6
(gdb) bt
#0 0x400fad95 in nanosleep () from /lib/libc.so.6
#1 0x0804a57e in ?? ()
#2 0xbffff860 in ?? ()
#3 0x00000000 in ?? ()
#4 0x00000000 in ?? ()
#5 0xbffff8cc in ?? ()
#6 0x00000000 in ?? ()
#7 0x407f4000 in ?? ()
#8 0x00000000 in ?? ()
#9 0x4006903e in __errno_location () from /lib/libc.so.6
#10 0x08048fe6 in ?? ()
#11 0x00000000 in ?? ()
#12 0x407f4000 in ?? ()
#13 0xbffff8d0 in ?? ()
#14 0x08049090 in ?? ()
#15 0x00000000 in ?? ()
#16 0x08048c80 in ?? ()
#17 0x0804ab16 in _IO_stdin_used ()
#18 0x0804ab0a in _IO_stdin_used ()
#19 0x00000000 in ?? ()
#20 0x0804c32c in ?? ()
#21 0xbffff8c8 in ?? ()
#22 0x00000000 in ?? ()
#23 0x00000000 in ?? ()
#24 0x407f4000 in ?? ()
#25 0xbffff8e8 in ?? ()
#26 0xbffffa38 in ?? ()
#27 0x00000000 in ?? ()
#28 0x407f4000 in ?? ()
#29 0xbffff944 in ?? ()
#30 0x40182880 in ?? () from /lib/libc.so.6
#31 0x40016540 in ?? () from /lib/ld-linux.so.2
#32 0xbffff944 in ?? ()
#33 0xbffff918 in ?? ()
#34 0x40068e36 in __libc_start_main () from /lib/libc.so.6
#35 0x40068e36 in __libc_start_main () from /lib/libc.so.6
#36 0x08048bd1 in ?? ()
(gdb)

Wayne

[PaX Team]

As the topic states -- any generated core files, attaching to the process, or even running the process under gdb, generates corrupt stack backtraces.

The system is 2.4.29 with grsecurity-2.1.3-2.4.29-200503070900.patch. The new header marking system is enabled, the old is disabled. This is a debian stable system.

i may be misunderstanding you but are you saying that under a non-grsecurity kernel the same gdb works properly?

[Razathorn]

As the topic states -- any generated core files, attaching to the process, or even running the process under gdb, generates corrupt stack backtraces.

The system is 2.4.29 with grsecurity-2.1.3-2.4.29-200503070900.patch. The new header marking system is enabled, the old is disabled. This is a debian stable system.

i may be misunderstanding you but are you saying that under a non-grsecurity kernel the same gdb works properly?

You understood me correctly, however, just in order to prevent a wild goose chase, I tried this on a non grsec system and the same results were observed. It would seem that this is not grsec's fault -- it's probably something to do with optimizations.

Dohs.