February 11th, 2021 at 9:55 PM
https://engineering.skroutz.gr/blog/unco...ux-kernel/
TLDR: a bug was found in the linux kernel affecting TCP socket connections which triggers under specific circumstances.
1. This bug will not be triggered by most L7 protocols. In “synchronous” request-response protocols such as HTTP, usually each side will consume all available data before sending. In this case, even if snd_wl1 wraps around, the bulk receiver will be left with a non-zero window and will still be able to send out data, causing the next acknowledgment to update the window and adjust snd_wl1 through check 1 in tcp_may_update_window. rsync on the other hand uses a pretty aggressive pipeline where the server might send out multi-GB responses without consuming incoming data in the process. Even in rsync’s case, using rsync over SSH (a rather common combination) rather than the plain TCP transport would not expose this bug, as SSH framing/signaling would most likely not allow data to queue up on the server this way.
2. Regardless of the application protocol, the receiver must remain long enough (for at least 2GB) with a zero send window in the fast path to cause a wrap-around — but not too long for ack_seq to overtake snd_wl1 again. For this to happen, there must be no packet loss or other conditions that would cause the fast path’s header prediction to fail. This is very unlikely to happen in practice as TCP itself determines the network capacity by actually causing packets to be lost.
3. Most applications will care about network timeouts and will either fail or reconnect, making it appear as a “random network glitch” and leaving no trace to debug behind.
So effectively it remained hidden by obscurity or a non obvious trigger condition that only recently became truly relevant.
TLDR: a bug was found in the linux kernel affecting TCP socket connections which triggers under specific circumstances.
1. This bug will not be triggered by most L7 protocols. In “synchronous” request-response protocols such as HTTP, usually each side will consume all available data before sending. In this case, even if snd_wl1 wraps around, the bulk receiver will be left with a non-zero window and will still be able to send out data, causing the next acknowledgment to update the window and adjust snd_wl1 through check 1 in tcp_may_update_window. rsync on the other hand uses a pretty aggressive pipeline where the server might send out multi-GB responses without consuming incoming data in the process. Even in rsync’s case, using rsync over SSH (a rather common combination) rather than the plain TCP transport would not expose this bug, as SSH framing/signaling would most likely not allow data to queue up on the server this way.
2. Regardless of the application protocol, the receiver must remain long enough (for at least 2GB) with a zero send window in the fast path to cause a wrap-around — but not too long for ack_seq to overtake snd_wl1 again. For this to happen, there must be no packet loss or other conditions that would cause the fast path’s header prediction to fail. This is very unlikely to happen in practice as TCP itself determines the network capacity by actually causing packets to be lost.
3. Most applications will care about network timeouts and will either fail or reconnect, making it appear as a “random network glitch” and leaving no trace to debug behind.
So effectively it remained hidden by obscurity or a non obvious trigger condition that only recently became truly relevant.
"I reject your reality and subsitute my own." - Adam Savage, Mythbusters
![[Image: 5.jpg]](http://www.nodiatis.com/pub/5.jpg)
