The bug was fixed by changing the sequence numbers to 64 bits, thereby making an overflow infeasible, and removing the overflow handling logic.
So the bug is still there then? It will just take longer to hit.
Until someone else decides to change the encoding of that field, for some reason, and not initialize it at 0. It instead starts with a random value (for safety reasons). Good luck figuring out that random crash that happens once in a blue moon.
Like I said in my original comment, not if a future kernel change randomized that value to make it unpredictable to attacks. Then the bug will be back.
The bug doesn't trigger when the counter resets to zero, the bug triggers when the counter reuses a previous value.
So:
A) There is no reason whatsoever to randomize the counter
B) Even if they did, it wouldn't be a problem because it would still take an absurdly long time to loop around to the starting positions.
So the bug is still there then? It will just take longer to hit.
Until someone else decides to change the encoding of that field, for some reason, and not initialize it at 0. It instead starts with a random value (for safety reasons). Good luck figuring out that random crash that happens once in a blue moon.