not sure if you heard already but Microsoft released their analysis of the CrowdStrike bug.
and it was a read-out-of-bounds memory safety bug.
but I should probably say it here, too. "Out of bounds memory safety bug" is the result. It's not the cause. The real cause is what Tavis O. pointed out in his deconstruction of the dump on Twitter.
We don't know what caused the actual out-of-bounds read. We need more information from crowdstrike, but there's 2 distinct possibilities given Tavis's work and the actual failures known in the industry:
- Use After Free (UAF)
- Uninitialized Data Access
I'm actually willing to bet real $$$ (from my absolutely empty bank account) that it's the second one. While the first could also be the case, note that multiple dumps from people have shown the address being jumped to that resulted in this "out of bounds read" was all over the place, which is consistent with: data being used after it was not supposed to be and being scribbled in by other values; or, data being accessed after it was set up but not initialized.
Under "Uninitialized Data Access", there are also 2 subcategories that are more interesting. Whether this was data off the programming stack (the compiler-managed data area that is often tiny and unused) or whether this came off the heap (data claimed by the program through use of malloc or VirtualAlloc or other memory-pulling function).
It is still, of course, a memory safety bug, but "out of bounds read" is the RESULT of a more intimate codebase failure. While fun and cool and interesting, I don't particularly care what that is here because ultimately that data pointer could have taken you anywhere in the address space (a crash is, arguably, better than suddenly getting unfettered access to other data structures or important information at this level). But out-of-bounds reads and thumping the bible for that is a red herring.