Uncovering a 24-year-old bug in the Linux Kernel (2021) • Hacker News Board

Re: Uncovering a 24-year-old bug in the Linux Kernel (2021)

#81

Post by apoikos » Tue, Oct 18, 2022, 11:27 AM UTC

genewitch wrote: post #76

omginternets wrote: post #43

Which kernel version has this patch?

it says it was put in to 5.10-rc1; however i noticed weird network issues beginning in june or july. I am wondering if it was put in to the kernel for 5.10 and then left "off by default" until this year. 5.15.32 was around the kernel where i noticed the issues start. If i'm just connected via SSH and streaming video from a LAN server, everything is great. if i go on youtube.com (or whatever), i'll get "network unreac…

The fix (commit 18ded910b58) went indeed into 5.10-rc1, and was effective day one (there is no provision for it to be turned off), so it's unlikely to have caused trouble when upgrading from 5.10 to 5.15. That said, there's a ton of changes in the networking stack between 5.10 and 5.15 - more than 10k commits for the stack and the drivers - any of which might introduce some breakage.

Re: Uncovering a 24-year-old bug in the Linux Kernel (2021)

#82

Post by ehvatum » Tue, Oct 18, 2022, 4:00 PM UTC

simtel20 wrote: post #33

sponaugle wrote: post #21

This was a cool example of a class of bugs that are both hard to find with no active example, and hard to prevent in complex systems. The optimization that was added many years ago for performance didn't update something that had a use case that was incompatible with not being updated in a very small number of circumstances. It is an interesting thought experiment to consider what kind of tool or automated detection…

It's a great question! Thinking back... At the time this bug was introduced it would probably have been cost prohibitive to create a test case. We were proud of 100mbit networks, had flaky nics the vendors didn't help maintain much of the time (and which were often broken in hardware) and the filesystem max file size was something like 2tb, and most drives wee're in the handful of gbs. Conceiving of testing for somet…

> perhaps flooding zeros across a TCP socket could work

Unconstrained zero sending is too fast; you would tend to flood the connection, causing packet loss, breaking you out of the fast path long before counter loop around. You would need to avoid saturating the network while still causing the recipient to fall behind.

Re: Uncovering a 24-year-old bug in the Linux Kernel (2021)

#83

Post by ehvatum » Tue, Oct 18, 2022, 4:10 PM UTC

verisimilitudes wrote: post #53

How is it possible for a TCP bug that leads to stuck connections to go unnoticed for 24 years? It's because the fools responsible never rewrite their code, use a broken language, and don't even try to prove half of the broken garbage they write. Then, when it turns out to have been broken for decades, they chuckle and shove another finger into another crack, never understanding how they misuse computers.

This is not an unsafe language failure! The same logic, ported to Python, would exhibit the same error.

Re: Uncovering a 24-year-old bug in the Linux Kernel (2021)

#84

Post by verisimilitudes » Tue, Oct 18, 2022, 8:16 PM UTC

ehvatum wrote: post #83

verisimilitudes wrote: post #53

How is it possible for a TCP bug that leads to stuck connections to go unnoticed for 24 years? It's because the fools responsible never rewrite their code, use a broken language, and don't even try to prove half of the broken garbage they write. Then, when it turns out to have been broken for decades, they chuckle and shove another finger into another crack, never understanding how they misuse computers.

This is not an unsafe language failure! The same logic, ported to Python, would exhibit the same error.

This is a bad language failure, however. The same logic, ported to Brainfuck, would exhibit the same stupidity.

The C language makes it unreasonably difficult to write anything, even before proving it to be correct.