Hello,
I tried to reproduce the issue.
The original logfile showed this part:
ending up
*** stack smashing detected ***: /<<PKGBUILDDIR>>/tools/.libs/test
terminated
======= Backtrace: =========
/lib/i386-linux-gnu/libc.so.6(+0x6737a)[0xf757e37a]
/lib/i386-linux-gnu/libc.so.6(__fortify_fail+0x37)[0xf760ed77]
/lib/i386-linux-gnu/libc.so.6(+0xf7d38)[0xf760ed38]
/<<PKGBUILDDIR>>/tools/.libs/libfxt.so.0(_fini+0x0)[0xf76e3774]
/<<PKGBUILDDIR>>/tools/.libs/libfxt.so.0(+0x7023)[0xf76e1023]
/<<PKGBUILDDIR>>/tools/.libs/libfxt.so.0(fxt_fdwrite+0x6d9)[0xf76ddff9]
/<<PKGBUILDDIR>>/tools/.libs/libfxt.so.0(fut_flush+0x169)[0xf76e3219]
/<<PKGBUILDDIR>>/tools/.libs/libfxt.so.0(fut_endup+0x31)[0xf76e3381]
/<<PKGBUILDDIR>>/tools/.libs/test(main+0x1b4)[0x565c8934]
/lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf6)[0xf752f276]
/<<PKGBUILDDIR>>/tools/.libs/test(+0xbf7)[0x565c8bf7]
======= Memory map: ========
Rebuilding in a Debian Stretch i386 VM does not show this failure.
But the offsets of the disassembly show still quite equal
to a local built package version:
(gdb) disassemble fxt_fdwrite
...
0xb7fc5ff0 <+1744>: pushl 0xc(%esp)
0xb7fc5ff4 <+1748>: call 0xb7fc4f80 <fkt_record_pids@plt>
0xb7fc5ff9 <+1753>: add $0x10,%esp
<- means we are currently in the fkt_record_pids function.
...
(gdb) disassemble fkt_record_pids,0xb7fc901e+0x20
0xb7fc8f4d <fkt_record_pids+669>: mov -0x1c(%ebp),%edi
0xb7fc8f50 <fkt_record_pids+672>: xor %gs:0x14,%edi
0xb7fc8f57 <fkt_record_pids+679>: jne 0xb7fc901e <fkt_record_pids+878>
<- means we jumped here to 878, so the stack canary above was no ok
0xb7fc8f5d <fkt_record_pids+685>: lea -0xc(%ebp),%esp
0xb7fc8f60 <fkt_record_pids+688>: pop %ebx
...
0xb7fc9019 <fkt_record_pids+873>: jmp 0xb7fc8f39 <fkt_record_pids+649>
0xb7fc901e <fkt_record_pids+878>: call 0xb7fcb760
<__stack_chk_fail_local>
0xb7fc9023: lea 0x0(%esi),%esi
<- equals "libfxt.so.0(+0x7023)" above -> meaning we are in
__stack_chk_fail_local
0xb7fc9029: lea 0x0(%edi,%eiz,1),%edi
0xb7fc9030 <fkt_load_pids+0>: push %ebp
Theat would mean the problem is within the "fkt_record_pids" function, as far
as I see.
Looking into that function the variable name reserves for the pid at most 5
bytes.
92 char
name[sizeof("/proc/")-1+5+sizeof("/task/")-1+5+sizeof("/stat")-1+1]="/proc/",*task,
*c;
As the original package rebuild happened in some cloud servers in a chroot I
might
suspect that the PID could have grown larger than 5 digits.
The i386 kernel refused to change /proc/sys/kernel/pid_max.
But in a Debian Buster amd64 VM I could manipulate it so the pids
can grow into 7 digits:
echo 4194304 > /proc/sys/kernel/pid_max
while true; do P=$(readlink /proc/self); L=${#P}; echo $P $L; [ "$L" -gt
"6" ] && break; done
So now PIDs are 7 digits. After the package was built:
cd fxt-0.3.2/tools/.libs
export LD_LIBRARY_PATH=.
gdb -q --args ./test
(gdb) b fkt_record_pids
(gdb) directory /home/benutzer/fxt-0.3.2/fxt-0.3.2/tools
(gdb) run
(gdb) b 95
(gdb) cont
(gdb) print sizeof(name)
$1 = 28
(gdb) print/x sizeof(name)
$2 = 0x1c
(gdb) print &name
$4 = (char (*)[28]) 0x7fffffffe2b0
(gdb) watch *(0x7fffffffe2b0+0x1c)
Hardware watchpoint 3: *(0x7fffffffe2b0+0x1c)
(gdb) cont
Continuing.
Hardware watchpoint 3: *(0x7fffffffe2b0+0x1c)
Old value = 0
New value = 116
fkt_record_pids (fxt=fxt@entry=0x555555559280, fd=fd@entry=3) at pids.c:135
135 if(
!recordrunningpid(name,pidname) )
(gdb) bt
#0 fkt_record_pids (fxt=fxt@entry=0x555555559280, fd=fd@entry=3) at pids.c:135
#1 0x00007ffff7fc1344 in fxt_fdwrite (fxt=0x555555559280, fd=3) at fxt.c:155
#2 0x00007ffff7fc6087 in fut_flush (filename=<optimized out>,
next_slot=<optimized out>, record_flush_events=record_flush_events@entry=0) at
fut_setup.c:410
#3 0x00007ffff7fc61e5 in fut_endup (filename=<optimized out>) at
fut_setup.c:472
#4 0x000055555555549f in main () at test.c:70
(gdb) call (size_t (*)(const char*))__strlen_sse2(name)
$5 = (size_t (*)(const char *)) 0x1d
I was not able to reproduce the stack smashing itself,
but probably it can be confirmed that the PIDs are after such a mass
rebuild are longer than 5 characters.
And that both times the "5" bytes are in line 92 are not enough.
Kind regards,
Bernhard
