Re: [Libunwind-devel] Segmentation fault while trying to access an address in a PROT_NONE page

[Paul Pluzhnikov]

On Tue, Sep 6, 2016 at 10:19 AM, Johannes Ziegenbalg <address@hidden> wrote:

Hello everybody.

While sampling with one of our tools I sometimes come across this bug.
If a sample is triggered, presumably while resolving a symbol of a
shared library, a SIGSEGV occurs.

As libunwind is iterating up the stack, it checks if the address at #20
(backtrace.txt) is accessible. But it's corresponding page is mapped
with the PROT_NONE property which is usually used for guard pages.
Since the memory is mapped correctly, calls to mincore() or msync()
succeed, stating that the address is valid. But what they don't test is
the actual accessibility of the address.

Me and a colleague of mine are not sure if it's even a valid address or
a bug of some other library. I however attached a test case to
reproduce the error (access_mem_test.c) and a possible patch that adds
the necessary accessibility test.
This test uses write() to check if the value at an address can be
written to a pipe. If the address is not accessible the write fails but
doesn't raise a signal. 

​FWIW, we've also been checking write() rather than mincore() since 2009.​

 

I'm certain, that the patch needs one or two more iterations e.g. the
pipe needs to be closed somewhere. Maybe you guys can help me out!

At a minimum, you probably want to set ​FD_CLOEXEC (or use pipe2(..., O_CLOEXEC)).

If the forked process continues without execve, it will need to reopen the pipe, so our patch is quite a bit more involved.

--

Paul Pluzhnikov