Port-sparc64 archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Someone using COMPAT_SVR4(_32) ?



On Wed, 13 Sep 2017, Jerome Ibanes wrote:

> 6.0.6 sparc64, 6.1.5 sparc64, 7.1 sparc64 (all GENERIC), fail with the same
> behavior (meaning, same ktrace ouput) given the same payload (sparc
> solaris 2.6), ktrace shows:
> 
> [...]
>   1119      1 k        CALL  mmap(0x2000,0x80000002,0,0x45f,2,0)
>   1119      1 k        RET   mmap 1074167808/0x40068000
>   1119      1 k        PSIG  SIGSEGV SIG_DFL: code=SEGV_MAPERR,
> addr=0x0, trap=48)

Hm.  What binary is this?  Solaris 2.6, so that's 32-bits, right?  
That's a really old version.  I should know, I got the tee shirt.  

Is that on a 32-bit or 64-bit NetBSD kernel?

Compat svr4_32 mmap should be this:

115     STD             { netbsd32_voidp|svr4_32_sys||mmap(netbsd32_voidp addr, 
                            svr4_32_size_t len, int prot, int flags, int fd, 
                            svr4_32_off_t pos); }

So according to ktrace, it's requesting some huuuuuuge mapping be added at 
address 0x2000 from FD 2.  

Hm.  Need to hunt down the man page for Solaris 2.6 mmap... which seems a 
bit difficult to find.  

Anyway, according to our svr4_mman.h SVR4_MAP_ANON is not set so mmap 
should be respecting the address.  Instead, it maps the file somewhere 
else completely.

Either ptrace is confused, the way we're interpreting the syscall args is 
wrong (maybe a newer version of Solaris that has different width size_t or 
off_t), or our mmap is broken and is ignoring the map address.

Anyway, to summarize, the process tries to map something at address 0x2000 
(page 2), but mmap() maps it at 0x40068000 instead, so when the process 
tries to access the mapped image at 0x2000 it faults.

Eduardo


Home | Main Index | Thread Index | Old Index