using the gcc-4.7.0 prerelease as packaged by Fedora Rawhide, there is a segfault in the program that results from compiling sha512-hash.c
Bug #931542 reported by
Zooko Wilcox-O'Hearn
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
gcc |
Invalid
|
Medium
|
|||
pycryptopp |
Fix Released
|
Unknown
|
|||
pycryptopp (Fedora) |
Invalid
|
High
|
|||
pycryptopp (Ubuntu) |
New
|
Undecided
|
Unassigned |
Bug Description
This doesn't *actually* affect Ubuntu yet, at least not until Ubuntu upgrades to gcc 4.7.0 and only if this bug is still present by then.
no longer affects: | pycryptopp |
Changed in gcc: | |
importance: | Unknown → Medium |
status: | Unknown → New |
Changed in pycryptopp: | |
status: | Unknown → New |
description: | updated |
Changed in gcc: | |
status: | New → Invalid |
Changed in pycryptopp: | |
status: | New → Fix Released |
Changed in pycryptopp (Fedora): | |
importance: | Unknown → High |
status: | Unknown → Invalid |
To post a comment you must log in.
Using this version of gcc-4.7.0 prerelease which is shipped in Fedora Rawhide: 4.7.0 20120126 (Red Hat 4.7.0-0.10), the resulting code segfaults. Valgrind reports this:
==9709== Invalid read of size 1 sign_publickey (ed25519.c:30) c:48) libpython2. 7.so.1. 0) libpython2. 7.so.1. 0) libpython2. 7.so.1. 0) libpython2. 7.so.1. 0) libpython2. 7.so.1. 0) libpython2. 7.so.1. 0) libpython2. 7.so.1. 0) libpython2. 7.so.1. 0) libpython2. 7.so.1. 0) a_suppression_ name_here> crypto_ hash_sha512 crypto_ sign_publickey ed25519_ publickey PyEval_ EvalFrameEx PyEval_ EvalCodeEx /usr/lib64/ libpython2. 7.so.1. 0 PyObject_ Call /usr/lib64/ libpython2. 7.so.1. 0 PyObject_ Call /usr/lib64/ libpython2. 7.so.1. 0 /usr/lib64/ libpython2. 7.so.1. 0 PyObject_ Call sign_publickey (ed25519.c:30) c:48) libpython2. 7.so.1. 0) libpython2. 7.so.1. 0) libpython2. 7.so.1. 0) libpython2. 7.so.1. 0) libpython2. 7.so.1. 0) libpython2. 7.so.1. 0) libpython2. 7.so.1. 0) libpython2. 7.so.1. 0) libpython2. 7.so.1. 0)
==9709== at 0xB4FEE70: crypto_hash_sha512 (sha512-hash.c:40)
==9709== by 0xB4F8F23: crypto_
==9709== by 0xB4F7EEB: ed25519_publickey (ed25519module.
==9709== by 0x4F0A153: PyEval_EvalFrameEx (in /usr/lib64/
==9709== by 0x4F0B7C0: PyEval_EvalCodeEx (in /usr/lib64/
==9709== by 0x4E9C2BA: ??? (in /usr/lib64/
==9709== by 0x4E78A1D: PyObject_Call (in /usr/lib64/
==9709== by 0x4E86EEF: ??? (in /usr/lib64/
==9709== by 0x4E78A1D: PyObject_Call (in /usr/lib64/
==9709== by 0x4ECBC41: ??? (in /usr/lib64/
==9709== by 0x4ECB8DB: ??? (in /usr/lib64/
==9709== by 0x4E78A1D: PyObject_Call (in /usr/lib64/
==9709== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==9709==
{
<insert_
Memcheck:Addr1
fun:
fun:
fun:
fun:
fun:
obj:
fun:
obj:
fun:
obj:
obj:
fun:
}
==9709==
==9709== Process terminating with default action of signal 11 (SIGSEGV)
==9709== Access not within mapped region at address 0x0
==9709== at 0xB4FEE70: crypto_hash_sha512 (sha512-hash.c:40)
==9709== by 0xB4F8F23: crypto_
==9709== by 0xB4F7EEB: ed25519_publickey (ed25519module.
==9709== by 0x4F0A153: PyEval_EvalFrameEx (in /usr/lib64/
==9709== by 0x4F0B7C0: PyEval_EvalCodeEx (in /usr/lib64/
==9709== by 0x4E9C2BA: ??? (in /usr/lib64/
==9709== by 0x4E78A1D: PyObject_Call (in /usr/lib64/
==9709== by 0x4E86EEF: ??? (in /usr/lib64/
==9709== by 0x4E78A1D: PyObject_Call (in /usr/lib64/
==9709== by 0x4ECBC41: ??? (in /usr/lib64/
==9709== by 0x4ECB8DB: ??? (in /usr/lib64/
==9709== by 0x4E78A1D: PyObject_Call (in /usr/lib64/
More detail, including access to a buildbot which can reliably reproduce the problem on Fedora Rawhide and demonstrate no such problem on several other platforms, is here: https:/ /tahoe- lafs.org/ trac/pycryptopp /ticket/ 80