Corrupted files can trigger stack overflow on deserialization

[Simon Paradis]

See https://bunny.net/blog/the-stack-overflow-of-death-dns-collapse/

excerpt from above link:
Turns out, the corrupted file caused the BinaryPack serialization library to immediately execute itself with a stack overflow exception, bypassing any exception handling and just exiting the process. Within minutes, our global DNS server fleet of close to a 100 servers was practically dead.

[Sergio Pedri]

Thanks for the report and for linking that blog post, I had missed it! 😄
Also I had no idea this library was being used by a team in such a scenario.

Anyway after checking the code I think it's safe to say the crash is likely coming from these bits:

BinaryPack/src/BinaryPack/Serialization/Processors/StringProcessor.cs

Lines 62 to 64 in b1d2644

 // Span<byte> span = stackalloc byte[length]; 
 il.EmitLoadLocal(Locals.Write.Length); 
 il.EmitStackalloc(); 

BinaryPack/src/BinaryPack/Serialization/Processors/StringProcessor.cs

Lines 113 to 116 in b1d2644

 // byte* p = stackalloc byte[length]; 
 il.MarkLabel(notEmpty); 
 il.EmitLoadLocal(Locals.Read.Length); 
 il.EmitStackalloc(); 

Right now the input size isn't checked, so it's very possible that either a file got corrupted as the blog post mentioned, causing a way too high number of bytes to be stackallocated, or maybe simply a string that was too long to fit on the stack was being serialized, and the library currently doesn't gracefully handle either case. The fix should be pretty simple though, mostly just adding a check to throw a catchable exception instead. Will work on that later today 🙂