Daniel Micay
Daniel Micay
Most issues like this are upstream memory corruption bugs uncovered by hardened_malloc. It uncovers latent memory corruption bugs as part of mitigating exploitation. However, in this case, I see `_int_free`...
@mike2307 Is this still an issue?
@mike2307 Can you try with v6 of hardened_malloc? There have been various little fixes over time since I last asked.
The safe_flag check is meant to deal with that. You should figure out why that's not working. The issue with -fstack-clash-protection is that it's not implemented on arm64 yet.
hardened_malloc only uses threads.h for `thread_local`. You can refer to it as `_Thread_local` instead if that's missing. It's just annoying.
Going to need to come up with a way of quantifying the possible security from this feature as part of choosing a design approach. It hasn't yet been implemented because...
It's not a bug. It's a false positive warning. This code comes from the ChaCha reference implementation and we don't want to change it much to avoid introducing any bugs.
It's not supported yet since `test/` doesn't support `VARIANT` yet. It has to be ported to using separate directories for the tests for separate variants.
Going to need to come up with a way of quantifying the possible security from this feature as part of choosing a design approach. It hasn't yet been implemented because...
The current code is here: https://github.com/GrapheneOS/hardened_malloc/blob/master/h_malloc.c#L353-L372