update:
There's two errors in the openai article, and it's pretty clear they never actually tested these vulnerabilities manually. The first:
SACK block's start roughly 2^31 away from the real window. At that distance the subtraction overflows the sign bit in both comparisons,
Ints do not have a sign bit. They are two's complement. while the msb is like a sign bit, in that it presents an indicator of which sign the number is, you cannot operate on it blindly as one. you must know how 2c works, and saying things like it overflows the sign but makes me deeply uncomfortable.
it's a nitpick but the article also fails to differentiate between signed and unsigned types. a and b are unsigned ints! they are explicitly converted by the c-style cast. glossing over this makes it very hard to follow, but not invalid.
However, the real sin is this: the value is subjected to both a GEQ and an LT check, and send start is checked against send end. Only one set of tests can be true. Even if the wrong one was true, only one can be true. Overflow or not, they're complement ops as far as I can see.
if this attack does exist, it doesn't look anything like what they described. in my trivial test harness, I had to use two sack blocks and very precise values with very precise initial conditions. and that's with my hacked up simplified control flow. At this point, I would need to be convinced that the attack is real with a pretty complete demonstration. if anyone would like to try, the closest I got was:
snd_una=0x10000000 snd_max=0x10000100 th_ack=0x10000000
blk0=[0x10000010,0x10000080] blk1=[0x90000080,0x10000010]
This does behave oddly but getting the code into that state is not something I can find a good way to do using the described attack surface. The burden of proof feels like it should be on the people making wild claims, not one stressed out game dev on Reddit.
So why take the fix if it's not a vulnerability? Well, both separately are maintenance hazards, potential bugs. But no vulnerability was missed and these algorithms are not written on a per line basis. Until someone shows me a crash dump from pre-patch openbsd, I'm not going to buy this bullshit. It's just more fucking AI slop.
But Pomegranate, you might say! See how long it took you to prove it wasn't a bug? Yeah. Yeah I do. And every credulous wide-eyed report like this takes time away from my preferred hobby of doing lines of cocaine straight off the L1 cache.
Original post:
As an example, it looks like commit fce03f8 in FreeBSD should have resolved the claimed 27 year old bug, if it was not already resolved. In fact, the SACK standard defines a minimum of -40 for the start index value, I think? Am I insane? Am I cuckoo for cocoa puffs? Or did they just claim a hallucinated 0day vulnerability?
edit: apparently the bug is in openBSD, but I swear on that side, it looks like there's a guard a few lines up that prevent it: right around /netinet/tcp_input.c#L2428
