bpo-28055: fix unaligned accesses in siphash24()#6123
Conversation
Sorry, something went wrong.
|
Hello, and thanks for your contribution! I'm a bot set up to make sure that the project can legally accept your contribution by verifying you have signed the PSF contributor agreement (CLA). Unfortunately we couldn't find an account corresponding to your GitHub username on bugs.python.org (b.p.o) to verify you have signed the CLA (this might be simply due to a missing "GitHub Name" entry in your b.p.o account settings). This is necessary for legal reasons before we can look at your contribution. Please follow the steps outlined in the CPython devguide to rectify this issue. Thanks again to your contribution and we look forward to looking at it! |
Sorry, something went wrong.
serhiy-storchaka
left a comment
serhiy-storchaka
left a comment
There was a problem hiding this comment.
Please open an issue on the bug tracker for discussion.
Sorry, something went wrong.
|
A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated. Once you have made the requested changes, please leave a comment on this pull request containing the phrase |
Sorry, something went wrong.
Sorry, something went wrong.
serhiy-storchaka
added
type-bug
An unexpected behavior, bug, or error
needs backport to 3.6
and removed
CLA not signed
labels
Mar 26, 2018
|
So other than a NEWS entry, is there anything else that needs to be done for this before merging? |
Sorry, something went wrong.
serhiy-storchaka
left a comment
serhiy-storchaka
left a comment
There was a problem hiding this comment.
Just a news entry is needed.
Sorry, something went wrong.
|
Ping |
Sorry, something went wrong.
The hash implementation casts the input pointer to uint64_t* and directly reads from this, which may cause unaligned accesses. Use memcpy() instead so this code will not crash with SIGBUS on sparc. https://bugs.gentoo.org/show_bug.cgi?id=636400
|
Thanks @DerDakon for the PR, and @serhiy-storchaka for merging it 🌮🎉.. I'm working now to backport this PR to: 3.6, 3.7. |
Sorry, something went wrong.
The hash implementation casts the input pointer to uint64_t* and directly reads from this, which may cause unaligned accesses. Use memcpy() instead so this code will not crash with SIGBUS on sparc. https://bugs.gentoo.org/show_bug.cgi?id=636400 (cherry picked from commit 1e2ec8a) Co-authored-by: Rolf Eike Beer <eike@sf-mail.de>
The hash implementation casts the input pointer to uint64_t* and directly reads from this, which may cause unaligned accesses. Use memcpy() instead so this code will not crash with SIGBUS on sparc. https://bugs.gentoo.org/show_bug.cgi?id=636400 (cherry picked from commit 1e2ec8a) Co-authored-by: Rolf Eike Beer <eike@sf-mail.de>
The hash implementation casts the input pointer to uint64_t* and directly reads from this, which may cause unaligned accesses. Use memcpy() instead so this code will not crash with SIGBUS on sparc. https://bugs.gentoo.org/show_bug.cgi?id=636400 (cherry picked from commit 1e2ec8a) Co-authored-by: Rolf Eike Beer <eike@sf-mail.de>
The hash implementation casts the input pointer to uint64_t* and directly reads from this, which may cause unaligned accesses. Use memcpy() instead so this code will not crash with SIGBUS on sparc. https://bugs.gentoo.org/show_bug.cgi?id=636400 (cherry picked from commit 1e2ec8a) Co-authored-by: Rolf Eike Beer <eike@sf-mail.de>
Like python#6123 this pointer may be unaligned, so a memcpy() instead of simple assignment is required for strict architectures e.g. sparc.
The hash implementation casts the input pointer to uint64_t* and directly reads from this, which may cause unaligned accesses. Use memcpy() instead so this code will not crash with SIGBUS on sparc.
https://bugs.gentoo.org/show_bug.cgi?id=636400
https://bugs.python.org/issue28055