Re: statethreads crashes in ld on 6.4

On Mon, 3 Dec 2018, Claus Assmann wrote:
> Here's the dissambler output and the ktrace output follows.
> Unfortunately I don't know enough about this to figure out
> what is wrong, hopefully someone else can (or tell me which
> other information is still needed). TIA!

A close read of the ktrace output points to the problem:

...
> 65554 server GIO fd 2 wrote 89 bytes
> "[03/Dec/2018:08:28:29] INFO: process 0 (pid 65554): starting 8 threads on localhost:1234
> "

So it's just about to create its eight (userspace) threads...


> 65554 server CALL mmap(0,0x12000,0x3<PROT_READ|PROT_WRITE>,0x1002<MAP_PRIVATE|MAP_ANON>,-1,0)
> 65554 server RET mmap 21771804393472/0x13cd24aac000
> 65554 server CALL mmap(0,0x12000,0x3<PROT_READ|PROT_WRITE>,0x1002<MAP_PRIVATE|MAP_ANON>,-1,0)
> 65554 server RET mmap 21771451404288/0x13cd0fa09000
> 65554 server CALL mmap(0,0x12000,0x3<PROT_READ|PROT_WRITE>,0x1002<MAP_PRIVATE|MAP_ANON>,-1,0)
> 65554 server RET mmap 21773345935360/0x13cd808cd000
> 65554 server CALL mmap(0,0x12000,0x3<PROT_READ|PROT_WRITE>,0x1002<MAP_PRIVATE|MAP_ANON>,-1,0)
> 65554 server RET mmap 21774756491264/0x13cdd4a03000
> 65554 server CALL mmap(0,0x12000,0x3<PROT_READ|PROT_WRITE>,0x1002<MAP_PRIVATE|MAP_ANON>,-1,0)
> 65554 server RET mmap 21774604423168/0x13cdcb8fd000
> 65554 server CALL mmap(0,0x12000,0x3<PROT_READ|PROT_WRITE>,0x1002<MAP_PRIVATE|MAP_ANON>,-1,0)
> 65554 server RET mmap 21773142749184/0x13cd74707000
> 65554 server CALL mmap(0,0x12000,0x3<PROT_READ|PROT_WRITE>,0x1002<MAP_PRIVATE|MAP_ANON>,-1,0)
> 65554 server RET mmap 21773994246144/0x13cda7314000
> 65554 server CALL mmap(0,0x12000,0x3<PROT_READ|PROT_WRITE>,0x1002<MAP_PRIVATE|MAP_ANON>,-1,0)
> 65554 server RET mmap 21774606540800/0x13cdcbb02000

Eight mmaps, presumably one per thread...


> 65554 server CALL kbind(0x7f7ffffd4fa8,24,0x8a4abe18ba78cb4a)
> 65554 server RET kbind 0

Okay, so this kbind() is by the original thread. The first argument to
kbind() happens to be a buffer which is always on the current thread's
stack. All is good here.

...
> 65554 server CALL kbind(0x13cd24abcc48,24,0x8a4abe18ba78cb4a)
> 65554 server PSIG SIGSEGV SIG_DFL addr=0x0 trapno=0
> 65554 server NAMI "server.core"

And now this kbind() call blows up: the address is not on the original
thread's stack but in one of those mmap()s...but those mmap()s were not
marked as stacks by including MAP_STACK. To quote the "Security
improvements" section of https://www.openbsd.org/64.html

* Implemented MAP_STACK option for mmap(2). At pagefaults and
syscalls the kernel will check that the stack pointer points
to MAP_STACK memory, which mitigates against attacks using
stack pivots.


To confirm, if you check your dmesg(8) or /var/log/messages you should
find the kernel complaining something like
syscall [server]65554/### sp 13cd24a## not inside 0x7f7f###-0x7f7f###


Philip Guenther