Comment by jiggawatts

3 years ago

> It does pretty much what you say: it repeatedly copies data (2 bytes at a time though), without materializing a string. So if the string you try to read is 10 packets long, you end up copying 1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 + 10 = 55 packets. If you need 100 packets, you end up copying them 5050 times. So to read N bytes you copy O(N^2) bytes: it's impossible to scale this way. Whether bytes are copied 2 at a time or using a more optimal algorithm doesn't really matter.

Good lord. It took them about a year to find this obvious O(n^2) hot loop and they’re unable the fix it.

To me it seems like the people writing that parser are just doing it piecemeal, adding little spot fixes instead of having a consistent and robust stream parser that won’t crash or slow down to molasses if you look at it wrong.

In several places they mention that the parser was never tested with partial buffer fills because replayed packet captures from disk don’t do that. Real network sockets do.

Suddenly I can see how the security bug happened where data was getting received by the wrong SqlConnection under high load.