Its a stack buffer overflow in our new hash table, in a call to crypto_atomic_load, specifically on a 32 bit build, and specifically in a threads_none build. Looks like maybe we're using 32 bit addresses as 64 bit values here, leading to an inappropriate stack corruption when we assign a 64 bit value to a 32 bit pointer.
Looks like maybe
### Tasks
- [x] download the fuzzer corpus that reproduced the crash
- [x] reproduce the problem locally
- [x] correct the code to properly treat the pointers as their required pointer types
- [x] confirm the stack corruption is resolved
We have a new clusterfuzz report: https://oss-fuzz.com/testcase-detail/5058079189172224
Its a stack buffer overflow in our new hash table, in a call to crypto_atomic_load, specifically on a 32 bit build, and specifically in a threads_none build. Looks like maybe we're using 32 bit addresses as 64 bit values here, leading to an inappropriate stack corruption when we assign a 64 bit value to a 32 bit pointer.
Looks like maybe