Hello, I am writing because I have a segmentation fault when remote-debugging a
PPC 32-bit target with gdbserver.
This is the same platform described in
'https://lore.kernel.org/linuxppc-dev/dc38afe9-6b78-f3f5-666b-986939e40...@keymile.com/',
although the bug does not seem to be the same and the position of the thread
struct does not affect it.
The segmentation fault message is the following:
tomcli[135]: User access of kernel address (dffbdf10) - exploit attempt? (uid:
0)
gdbserver is sometimes unresponsive, although sometimes I am able to kill it
with CTRL+C.
The code I use to reproduce this (tomcli) is the same as my colleague sent back
in 2016:
--- snip -----
#include <pthread.h>
#include <stdio.h>
#include <unistd.h>
void * th_1_func()
{
while (1) {
sleep(2);
printf("Hello from thread function 1)\n");
}
}
int main() {
int err;
pthread_t th_1, th_2, th_3;
err = pthread_create(&th_1, NULL, th_1_func, NULL);
if (err != 0)
printf("pthread_create\n");
err = pthread_create(&th_2, NULL, th_1_func, NULL);
if (err != 0)
printf("pthread_create\n");
err = pthread_create(&th_3, NULL, th_1_func, NULL);
if (err != 0)
printf("pthread_create\n");
while(1) {}
return 0;
}
--- snap ---
This can be reproduced always by starting the debug session, stepping 5 times
and then issuing a continue.
Sometimes just a continue will do.
This error is also happening sporadically when running our main application
under gdbserver, we get a segmentation fault in dl_fixup.
It never happens during normal runtime.
The address that the kernel complains about is coming from pt_regs->gpr[3].
This value is put in the register in a call to PTRACE_SINGLESTEP (value 9).
I poked around the ptrace code a bit, seeing if there were any possible
overflows but I could not find anything, so maybe I'm barking up the wrong
tree, although it does seem to be related to ptrace.
I also added a dump_stack before the "exploit attempt" message:
CPU: 3 PID: 135 Comm: tomcli Not tainted 6.1.133-00564-g0c302b26a2c4-dirty #0
Hardware name: name,prodname e5500 0x80241021 CoreNet Generic
Call Trace:
[c2bf5e90] [c0adfde8] dump_stack_lvl+0x4c/0x6c (unreliable)
[c2bf5eb0] [c0032ec8] ___do_page_fault+0x1c8/0x6b0
[c2bf5ee0] [c003340c] do_page_fault+0x5c/0x150
[c2bf5f00] [c000091c] DataStorage+0x15c/0x180
--- interrupt: 300 at 0xb7fe5dd8
NIP: b7fe5dd8 LR: b7fe5d78 CTR: b7fefb50
REGS: c2bf5f10 TRAP: 0300 Not tainted (6.1.133-00564-g0c302b26a2c4-dirty)
MSR: 0002d002 <CE,EE,PR,ME> CR: 20000208 XER: 20000000
DEAR: dffbdf10 ESR: 00000000
GPR00: b7fe705c bffff940 c27c3480 dffbdf10 b7fe7f70 00000000 b7ffdbdc b7fca000
GPR08: b7fffa78 b7ffdbc8 ffffffff fffffffc b7feed88 00000000 00000000 00000000
GPR16: 0000fff1 bffffd40 b7fca330 00000000 00000000 00000001 bffffd40 00000000
GPR24: bffffab0 b7fe7f70 b7ffdbc8 dffbdf14 dffbdf10 b7fff010 b7ffeff4 bffffa70
NIP [b7fe5dd8] 0xb7fe5dd8
LR [b7fe5d78] 0xb7fe5d78
--- interrupt: 300
tomcli[135]: User access of kernel address (dffbdf10) - exploit attempt? (uid:
0)
Finally, here's the GDB stepping, continue and backtrace at the crash:
(gdb) target remote 192.168.1.68:1234
Remote debugging using 192.168.1.68:1234
Reading symbols from /nfsroot/pbecqoriq_ppc32/prodname/lib/ld.so.1...
Reading symbols from /nfsroot/pbecqoriq_ppc32/prodname/lib/.debug/ld.so.1...
_start () at ../sysdeps/powerpc/powerpc32/dl-start.S:32
warning: 32 ../sysdeps/powerpc/powerpc32/dl-start.S: No such file or
directory
(gdb) s
35 in ../sysdeps/powerpc/powerpc32/dl-start.S
(gdb) s
36 in ../sysdeps/powerpc/powerpc32/dl-start.S
(gdb) s
_start () at ../sysdeps/powerpc/powerpc32/dl-start.S:40
40 in ../sysdeps/powerpc/powerpc32/dl-start.S
(gdb) s
41 in ../sysdeps/powerpc/powerpc32/dl-start.S
(gdb) s
_dl_start (arg=0xdffcff10) at rtld.c:536
warning: 536 rtld.c: No such file or directory
(gdb) s
538 in rtld.c
(gdb) c
Continuing.
Program received signal SIGSEGV, Segmentation fault.
0xb7fe5dd8 in _dl_sysdep_parse_arguments (args=0xbffffa18,
start_argptr=0xdffcff10)
at /usr/src/debug/glibc/2.39+git/sysdeps/unix/sysv/linux/dl-sysdep.c:80
warning: 80
/usr/src/debug/glibc/2.39+git/sysdeps/unix/sysv/linux/dl-sysdep.c: No such file
or directory
(gdb) bt
#0 0xb7fe5dd8 in _dl_sysdep_parse_arguments (args=0xbffffa18,
start_argptr=0xdffcff10)
at /usr/src/debug/glibc/2.39+git/sysdeps/unix/sysv/linux/dl-sysdep.c:80
#1 _dl_sysdep_start (start_argptr=start_argptr@entry=0xdffcff10,
dl_main=0xb7fe7f70 <dl_main>)
at /usr/src/debug/glibc/2.39+git/sysdeps/unix/sysv/linux/dl-sysdep.c:107
#2 0xb7fe705c in _dl_start_final (arg=arg@entry=0xdffcff10,
info=info@entry=0xbffffab0) at rtld.c:494
#3 0xb7fe7724 in _dl_start (arg=0xdffcff10) at rtld.c:583
#4 0xb7fec240 in _start () at ../sysdeps/powerpc/powerpc32/dl-start.S:41
(gdb)
I tested the exact same kernel and toolchain on a different powerpc platform
(mpc83xx) and the problem is not present.
I am not sure how to proceed or how to tell if the problem is the value being
put there or the code picking up that value to dereference it. Any tips?
Tomas Alvarez Vanoli
