Esiste un bug in macOS che agisce come una bomba a orologeria silenziosa: dopo circa 49,7 giorni di accensione continuativa, le connessioni TCP smettono di funzionare. Il sistema sembra perfettamente connesso, il ping risponde, eppure navigazione web, SSH, database remoti e qualsiasi servizio basato su TCP vanno in tilt. A scoprirlo sono stati i ricercatori di Photon, che hanno analizzato a fondo il problema identificandolo nel kernel XNU, il cuore del sistema operativo Apple.
Cosa succede con il bug di macOS?
La questione ha radici storiche. Bug di questo tipo hanno afflitto diversi sistemi operativi fin dagli anni Novanta, e sono tutti legati a un concetto tecnico che, semplificando molto, funziona così: alcuni contatori interni usano numeri a 32 bit, che possono contare fino a un valore massimo preciso. Superato quel limite, il contatore riparte da zero. Nel caso specifico di macOS, i timestamp TCP si basano proprio su un contatore di questo tipo. Fatti due calcoli, 2³² millisecondi equivalgono a circa 49,7 giorni. Raggiunta quella soglia, il contatore si azzera (un fenomeno chiamato rollover) e lo stack di rete del sistema operativo inizia a comportarsi in modo anomalo.
Il protocollo TCP usa questi timestamp per gestire la latenza e per evitare di ricevere pacchetti duplicati. Quando il contatore riparte da zero, i valori temporali diventano incoerenti rispetto alle connessioni già attive. Alcuni algoritmi interni, come il cosiddetto PAWS (Protect Against Wrapped Sequence numbers), danno per scontato che il tempo avanzi sempre. Dopo il rollover, questa assunzione viene violata e il kernel può scartare pacchetti perfettamente validi, trattandoli come obsoleti. Il risultato pratico è che le sessioni TCP si bloccano e le nuove connessioni non riescono a stabilirsi.
La rete funziona, ma TCP no: ecco perché è così difficile da diagnosticare
La parte più insidiosa di questo bug macOS è che non tutto smette di funzionare. I protocolli che non dipendono da TCP, come ICMP, continuano a operare normalmente. Questo significa che un semplice test con il ping dà risultati positivi, facendo credere che la rete sia perfettamente operativa. Nel frattempo, però, tutte le comunicazioni che passano per TCP (e sono la stragrande maggioranza: HTTP, HTTPS, SSH, connessioni a database) diventano inaffidabili o si fermano del tutto.
Chi si trova davanti a questo problema vede applicazioni bloccate, pagine web che non caricano e servizi apparentemente offline, ma senza alcun errore esplicito a livello di sistema. Il malfunzionamento resta confinato allo stack TCP del kernel e non coinvolge interfaccia di rete né driver fisici. I pacchetti continuano a essere trasmessi, ma il kernel non riesce più a gestirli correttamente a livello di sessione.
Chi è più a rischio e come proteggersi
Il problema colpisce soprattutto chi tiene il proprio Mac acceso per settimane senza mai riavviarlo: workstation di sviluppo, server macOS usati per test, sistemi embedded o configurazioni che evitano i riavvii. In questi ambienti il bug si presenta con precisione matematica una volta superata la soglia dei 49 giorni, spesso senza alcun segnale premonitore. Vale anche la pena considerare che standby e sospensione possono influenzare il comportamento: in certi scenari il reset parziale dello stack di rete ritarda la manifestazione del problema, rendendo ancora più complicato collegarlo all’uptime effettivo.
In assenza di una patch ufficiale da parte di Apple, la contromisura più pratica è un riavvio periodico del sistema prima di raggiungere la soglia critica. Un intervallo prudente di 30 o 40 giorni riduce il rischio senza impatti significativi sull’operatività quotidiana. Per chi gestisce più macchine, è possibile automatizzare riavvii controllati tramite strumenti come launchd o cron, soprattutto in ambienti dove il processo può essere pianificato. La soluzione definitiva richiederebbe un intervento a livello di kernel: l’adozione di contatori a 64 bit oppure una gestione esplicita del rollover nei timestamp TCP, interventi tutt’altro che banali perché coinvolgono componenti critici dello stack di rete e devono restare compatibili con le implementazioni esistenti.