Tahoe TCP Overflow Bug
After exactly 49 days, 17 hours, 2 minutes, and 47 seconds of continuous uptime, a 32-bit unsigned integer overflow in Apple’s XNU kernel freezes the internal TCP timestamp clock. Once frozen, TIME_WAIT connections never expire, ephemeral ports slowly exhaust, and eventually no new TCP connections can be established at all. ICMP (ping) keeps working. Everything else dies. The only fix most people know is a reboot.
[…]
This is a 32-bit unsigned integer timer wraparound bug in the TCP subsystem, specifically a TCP timestamp counter overflow. The counter in question,
tcp_now, is the kernel’s internal TCP clock. When it stops ticking, every timer in the TCP stack that depends on it stops working.
They suggest that the bug may have been around since Catalina, but I’ve had a Mac server running from the Catalina days all the way through Sequoia, with months of uptime, and haven’t seen this problem. I’ve not updated the server to Tahoe yet.
Previously:
Update (2026-04-08): Jason Snell:
As someone who keeps a Mac mini running in my closet, I guarantee you that I have been affected by this bug. […] Unless I’m traveling, I just shrug, reboot the Mac, and go on with my life.
Update (2026-04-10): John Gruber:
I think this bug is new to Tahoe. If you look at Apple’s open-source XNU kernel code — e.g. lines 3,732 to 3,745 in tcp_subr.c — you can see that the lines assigning the time in milliseconds to a
uint32_tvariable were checked in just six months ago, whereas most of the file is five years old. Also, I personally ran my MacBook Pro — at the time, running MacOS 15.7.2 Sequoia — up to 91 days of uptime in January.
See also: Adam Engst.
8 Comments RSS · Twitter · Mastodon
One of the reasons I switched to Mac as a Windows network admin many years ago was supposed to be for the networking.
This may have been a mistake in restrospect.
What an incredibly stupid bug, probably an overzealous wraparound guard check introduced routinely without appreciating the reason for the counter. But, ironically, just as with a similar bug in Windows 95, it will probably not be detected by most users, who will of course need to reboot long before it actually becomes a problem due to updates. Still, maybe it just doesn't matter anymore, since Apple doesn't make servers or server software for production use.
@Michael It looks like this was introduced with 26 (surprise, surprise), however the problems wouldn't actually manifest until you began running out of ephemeral ports, so depending on how busy your "server" actually was, you may not run into it for quite some time.
Yeah but, you know, "regular rebooting is good preventative maintenance for a Mac" according to the new generation of Apple sites.
OH this explains why randomly my iMac would REFUSE to do any connections to anything. I never put together that it was because of uptime!
The Photon paper has 2 references to similar behaviour in Apple Discussions. Reading those it is clear that the mis-behaviour became apparent within a few hours. There is nothing in the Photon paper to substantiate saying it might go back to Catalina. I wish that Photon had specified the macOS version on their servers. Almost certainly it is much newer than Catalina - perhaps Tahoe?
@Gilby I think the Catalina hypothesis came from this post, but it sounds like a different issue to me. It seems likely that this bug started with Tahoe.
