8 ms·
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 s
by alain94040 8y ago
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.
- jacquesm 8y ago> So the bug is still there then? It will just take longer to hit. It will take so long that the hardware will have died many times over before the bug triggers, assuming society as we know it is still around.
- alain94040 8y agoLike 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.
- deleted 8y ago[deleted]
- winstonewert 8y agoThe 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.