[caf]

What's interesting is that this is a protocol bug, not an implementation/software bug (in RFC 5961).

It is intriguing to realize that the three information leakages are enabled by the three (and only three) conditions that trigger challenge ACKs...

Indeed. It almost looks like an intentional back door.

[e40]

If your comment is true, then the title is misleading. It's not just Linux that is vulnerable, right?

[zokier]

Of major operating systems Linux is the only one that implements that part of the RFC

[X86BSD]

In whole or in part? Because FreeBSD partially supports it and one of the authors of the RFC, Randal Stewart, is a FreeBSD source committer.

[jfindley]

Linux is the only OS that fully implements the RFC, and thus the only one that's vulnerable. OSX, Windows and FBSD either don't implement it or partially implement it, making them not vulnerable.

[haasn]

I still think the title is misleading. Compare:

“A TCP weakness in Linux systems allows ...” vs “A TCP weakness allows ... on Linux systems”

Technically, it's not just Linux that's affected - it's the TCP protocol itself. The “on Linux systems” part is sort of redundant, and only serves to point out that other operating systems are unaffected as they don't implement that part of the RFC.

[cjbprime]

Not quite -- the RFC recommended rate limiting challenge ACKs, but it didn't say to do it with a per-system global variable that would leak shared state. From the paper:

> Therefore, the Linux kernel has faithfully implemented this feature by storing the challenge ACK counter in a global variable shared by all TCP connections. This approach, unfortunately, creates an undesirable side channel, as will be elaborated.

I think it's reasonable to call it a Linux bug. You can certainly criticize the RFC as failing to disclose (or more likely, failing to realize) the risk of an insecure implementation with side channels.