MacOS Seemingly Crashes After 49 Days of Uptime — a ‘Feature’ Perhaps Exclusive to Tahoe

Key Takeaways

• macOS 15.7.2 (Tahoe) crashes after 49d 17h 2m 47s uptime
• Overflow occurs in XNU kernel’s TCP timestamp 32‑bit counter
• Only ICMP ping remains functional; full reboot required
• Photon working on patch; Apple has not yet released fix

Pulse Analysis

The newly identified macOS bug stems from a classic 32‑bit unsigned integer overflow. When the kernel’s TCP timestamp counter, stored in a uint32_t, reaches its maximum value after roughly 49.7 days, the timestamp wraps to zero, halting the internal TCP clock. While ICMP echo requests still receive replies, all other network‑dependent services stall, leaving the system effectively frozen until a manual restart. This failure mode was exposed by Photon, whose service relies on sustained Mac uptime to route iMessage traffic, prompting a deep dive into the XNU source that revealed the recent code change in tcp_subr.c as the trigger.

For businesses that run macOS machines as servers, kiosks, or in continuous‑integration pipelines, the bug poses a tangible risk. Organizations often schedule maintenance windows based on predictable uptime, and an unexpected reboot after just over six weeks can interrupt critical workflows, degrade user experience, and inflate support costs. Historically, Apple touted Mac reliability, with users reporting uptime exceeding three months on pre‑Tahoe releases. The new limitation erodes that reputation and forces IT teams to implement work‑arounds such as automated reboots or monitoring scripts, which add operational overhead.

Apple’s response will be closely watched. The XNU kernel is open‑source, and the offending lines were committed only six months ago, suggesting the overflow was introduced inadvertently during a recent networking enhancement. While Photon is engineering a temporary patch, a definitive fix will likely require an OS update that expands the timestamp field or switches to a 64‑bit counter. Enterprises should stay alert for Apple’s forthcoming security bulletin and consider interim mitigation strategies, such as scheduled reboots before the 49‑day threshold, to maintain service continuity.