[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
libsigsegv 2.5: bug in OpenBSD4.0
From: |
Eric Blake |
Subject: |
libsigsegv 2.5: bug in OpenBSD4.0 |
Date: |
Thu, 17 Jul 2008 07:29:32 -0600 |
User-agent: |
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.14) Gecko/20080421 Thunderbird/2.0.0.14 Mnenhy/0.7.5.666 |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
In porting c-stack to use libsigsegv, I discovered a bug in libsigsegv 2.5
on OpenBSD 4.0.
When using both stackoverflow_install_handler and segv_handler_missing, a
SIGSEGV from dereferencing NULL will be wrongly treated as a stack
overflow on platforms that use mincore to check if the fault is near the
stack. In stackvma-mincore.c, mincore_is_near_this recognizes that
computation of a target address in between the fault and the stack causes
overflow, but then it calls is_unmapped(0,0) anyway. Since the page
containing 0 is unmapped, this results in claiming that a fault on NULL is
treated as a fault near the stack, and the stack overflow handler is
incorrectly invoked.
Is this the correct patch? Or is it still possible to have a stack vma
where the computation overflows, but where the faulting address is closer
to the stack than to any other vma?
- --- src/stackvma-mincore.c.orig 2008-07-17 07:21:23.255216900 -0600
+++ src/stackvma-mincore.c 2008-07-17 07:19:27.552091900 -0600
@@ -226,7 +226,7 @@
~ But be careful about overflow. */
~ unsigned long testaddr = addr - (vma->start - addr);
~ if (testaddr > addr) /* overflow? */
- - testaddr = 0;
+ return 0;
~ return is_unmapped (testaddr, addr);
~ }
- --
Don't work too hard, make some time for fun as well!
Eric Blake address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkh/STwACgkQ84KuGfSFAYBL3wCfeXF0cZRR2QUenVOvkZA41Q9q
0KAAn1leeFmx2FmngXD+Hed1K+Ks2dJU
=6wVK
-----END PGP SIGNATURE-----
- libsigsegv 2.5: bug in OpenBSD4.0,
Eric Blake <=