Olaf and a busy Russian pushed me in the right direction. A third-party shared object was poisoning my stacks.
But it was not directly related to my main executable. Both ldd and lddtree did not show libraries with RWE stacks, so I decided to go deeper and wrote a script that checked all the shared objects that are currently mapped to the process memory:
#!/bin/bash if [ -z "$1" ]; then echo "Usage: $0 <target>" exit 1; fi kav_pid=`pidof $1` for so in `cat /proc/$kav_pid/task/*/maps | awk '/.so$/ {print $6}' | sort | uniq`; do stack_perms=`readelf -Wl $so | awk '/GNU_STACK/ {print $7}'` if [ -z "$stack_perms" ]; then echo "$so doesn't have PT_GNU_STACK" elif [ "$stack_perms" != "RW" ]; then echo "$so has unexpected permissions: $stack_perms" fi done
And it worked! I found a library with RWE permissions:
$ ./find_execstack.sh target /target/dir/lib64/lib3rdparty.so has unexpected permissions: RWE
To make sure that it was this library that poisoned my stacks, I opened my application with gdb and set a breakpoint in dlopen . And bingo! Here are the permissions before dlopen ing lib3rdparty.so:
7ffffffde000-7ffffffff000 rw-p 00000000 00:00 0 [stack]
And here they are right after dlopen :
7ffffffde000-7ffffffff000 rwxp 00000000 00:00 0 [stack]
As it turned out, lib3rdparty.so was built using a different lib3rdparty.so and is now lib3rdparty.so .
Olaf, Russian, thanks!
Nikita Kakuev
source share