| delorie.com/archives/browse.cgi | search |
Corinna Vinschen wrote:
> And that's what I get in the Perl testcase:
>
> (gdb) x/xw 0x7efdd000
> 0x7efdd000: 0x0088ce68
> (gdb) x/2xw 0x0088ce68
> 0x88ce68: 0x0088400c 0x6103ce20 <-- Cygwin exception handler
> (gdb) x/2xw 0x0088400c
> 0x88400c: 0x00000000 0x00000001 <-- Huh?
>
> This looks wrong, doesn't it? The question is now, how and why does
> that happen?
> Where's the 0x00000000 pointer coming from on 2008? Is it possible that
> the OS overwrote the entry because it appears to be an address in Perl's
> stack, so it's a potential security theat?
The addresses are in the wrong order; SEH registration records should
always nest in the same way as stack call frames, i.e. unwinding toward
ascending memory addresses, but the second record is at a lower address than
the first, so the chain has been mangled somehow. Perhaps that breaks an
integrity check in the kernel? Where actually is $esp at the time; is the
bogus one in an already-released frame below $esp?
You might want to try again with a watchpoint:
watch *(unsigned int*)0x88ce68
... and see how and where that head entry gets set up and whether it
subsequently gets overwritten somehow.
cheers,
DaveK
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
| webmaster | delorie software privacy |
| Copyright © 2019 by DJ Delorie | Updated Jul 2019 |