cryptenroll --recovery-key crashes #19203
Comments
|
this is weird, really weird. must be some memory corruption somewhere. But I can't see it. Maybe the memory is corrupted elsewhere, and it just becomes visible in make_recovery_key(). Any chance you can reproduce this in valgrind with debug symbols? |
poettering
added
cryptsetup
needs-reporter-feedback ❓
|
Works perfectly fine under valgrind ¯\_(ツ)_/¯ |
|
worked fine here too... weird weird weird. |
|
no idea what to propose next |
Let's ensure our key sizes calculations are correct. This doesn't actually change anything, just adds more safety checks. Inspired by systemd#19203, but not a fix.
|
Figured out why binaries from Arch's packaging crash and my manual git builds don't. Arch packages are built with for the record, Arch's standard cflags up until now were: (They changed recently, but I still have the old configuration on this machine.) |
|
So it crashes inside I noticed that even though only 32 bytes were allocated, So explicit_bzero() gets called with len=40, which is compared against |
|
so some time back we ran into this already with valgrind, and after discussing with glibc upstream and people we agreed that our logic was right and that valgrind should be fixed to honour malloc_usable_size(key)... i have the suspicion that gcc's fortify should be fixed the same way. that said, maybe we can do something on our side too, and before relying on malloc_usable_size() call realloc() first with that size, which should then update the size in all static checkers too. |
|
See #12965 |
|
In particular this: https://sourceware.org/bugzilla/show_bug.cgi?id=24775#c6 Where Florian Weimer makes clear that msan was borked, because it didn't fix up malloc_usable_size() to return what was usable... hence I#d argue the fortify stuff in gcc is similarly broken and should be fixed. I am a bit curious why this never has shown up on Fedora like this, we use the same fortify settings after all |
Let's ensure our key sizes calculations are correct. This doesn't actually change anything, just adds more safety checks. Inspired by #19203, but not a fix.
|
Hi, any news on this issue ? |
It's a wrapper around malloc_usable_size() that is supposed to be compatible with _FORTIFY_SOURCES=1, by taking the __builtin_object_size() data into account, the same way as the _FORTIFY_SOURCES=1 logic does. Fixes: systemd#19203
It's a wrapper around malloc_usable_size() that is supposed to be compatible with _FORTIFY_SOURCES=1, by taking the __builtin_object_size() data into account, the same way as the _FORTIFY_SOURCES=1 logic does. Fixes: systemd#19203
It's a wrapper around malloc_usable_size() that is supposed to be compatible with _FORTIFY_SOURCES=1, by taking the __builtin_object_size() data into account, the same way as the _FORTIFY_SOURCES=1 logic does. Fixes: systemd#19203
It's a wrapper around malloc_usable_size() that is supposed to be compatible with _FORTIFY_SOURCES=1, by taking the __builtin_object_size() data into account, the same way as the _FORTIFY_SOURCES=1 logic does. Fixes: systemd#19203
It's a wrapper around malloc_usable_size() that is supposed to be compatible with _FORTIFY_SOURCES=1, by taking the __builtin_object_size() data into account, the same way as the _FORTIFY_SOURCES=1 logic does. Fixes: systemd#19203
It's a wrapper around malloc_usable_size() that is supposed to be compatible with _FORTIFY_SOURCES=1, by taking the __builtin_object_size() data into account, the same way as the _FORTIFY_SOURCES=1 logic does. Fixes: systemd#19203
keszybz
removed
the
needs-reporter-feedback ❓
systemd version the issue has been seen with
Used distribution
Linux kernel version used (
uname -a)CPU architecture issue was seen on
Expected behaviour you didn't see
Unexpected behaviour you saw
Steps to reproduce the problem
Additional program output to the terminal or log subsystem illustrating the issue
Backtrace:
Annoyingly, if I just compile the same v248 from git it seems to work fine.
The text was updated successfully, but these errors were encountered: