There could be an unintentional or flawed kernel change. Someone could use the code on a different OS with a different behaving or buggy kernel.
Or, the crime of making someone understand everything in order to understand some thing...
yep, he recognizes this also. strange to call this a bug then
i also find it strange that …
> As someone who has done a lot of work on ping(8)
… ping has a lot of work done to it
* Puts burden on readers to know or find out if something else already protects the bug from being exploitable, instead of just having a check in the code. That's trivia masquerading as an optimization.
* A bug or change in behavior in one program (the kernel) could cause a bug in another program (ping) due to assumptions, which may not even have been documented as never changing guarantees. Could make a bug somewhere grow into a worse bug elsewhere, as well as being harder to debug.
* It allows the program to be fuzzed or statically analyzed for any bugs without having to constrain what inputs are considered valid enough, adding maintenance costs and opening for accidentally limiting too much and hiding exploitable bugs.
* Another option to be clear that this is impossible and thus correct code would have been to assert that the user data never looks like this. A failed assert is better than an infinite loop, so this is an improvement. However this would make it blindingly clear that user input is trusted, making it too obvious to ignore the next improvement; to check and handle the issue, even if that input passed through another program first.
https://github.com/openbsd/src/blob/4628c0e6cf9bd4a6d679c314...
Sure his fix made it more robust, but the problem only showed up because he had his fuzzer bypass validation that was being done outside of the function.