Bug macOS blocca TCP dopo 49 giorni: cosa succede davvero

Un comportamento anomalo nella gestione delle connessioni TCP su macOS riporta alla memoria difetti storici legati ai limiti degli interi a 32 bit: errori silenziosi, difficili da diagnosticare e spesso ignorati fino alla loro manifestazione. Una recente analisi tecnica elaborata dai ricercatori di Photon ha individuato un problema nel kernel XNU che emerge dopo circa 49,7 giorni di uptime continuo, causando un blocco delle comunicazioni TCP pur in presenza di una rete funzionante.

Il fenomeno non nasce dal nulla. Bug simili hanno accompagnato diversi sistemi operativi sin dagli anni ’90, quando il conteggio del tempo era affidato a variabili limitate cioè numeri che possono rappresentare solo un intervallo finito di valori e che, una volta raggiunto il limite massimo, possono azzerarsi o generare errori di calcolo.

La soglia dei 49 giorni deriva infatti da un overflow tipico: 2³² millisecondi corrispondono a circa 49,7 giorni. In macOS, i timestamp TCP (valori numerici usati per monitorare e ottimizzare la trasmissione dei dati sulla rete) sono basati su un contatore a 32 bit: quando questo contatore raggiunge il valore massimo e riparte da zero (fenomeno chiamato rollover), può verificarsi un’alterazione nel funzionamento dello stack di rete, cioè il componente del sistema operativo che gestisce le comunicazioni.

Una “bomba a orologeria” in macOS

In condizioni normali, il protocollo TCP utilizza i timestamp per migliorare la gestione della latenza e prevenire problemi come la ricezione di pacchetti duplicati. Tuttavia, quando il contatore si azzera, i valori temporali diventano incoerenti rispetto allo stato delle connessioni attive. Il risultato è un comportamento anomalo: le sessioni TCP esistenti smettono di funzionare correttamente, mentre nuove connessioni possono fallire o restare in sospeso.

Alcuni algoritmi, come PAWS (Protect Against Wrapped Sequence numbers) assumono che il tempo sia sempre crescente. Dopo il rollover, tale ipotesi viene violata e il kernel può interpretare pacchetti validi come obsoleti o non validi, interrompendo di fatto il traffico di rete.

Photon descrive il bug individuato in macOS come una sorta di bomba a orologeria, pronta a detonare trascorsi poco più di 49 giorni. A meno che l’utente non riavvii prima il sistema.

Perché il sistema continua a rispondere ma TCP si blocca

I protocolli che non dipendono da TCP, come ICMP, spiegano i ricercatori, continuano a funzionare. Di conseguenza, operazioni come il ping restituiscono risultati regolari, dando l’impressione che la rete sia operativa.

Al contrario, tutte le comunicazioni basate su TCP – HTTP, HTTPS, SSH, database remoti – diventano inaffidabili o cessano completamente. L’utente osserva applicazioni bloccate, connessioni che non si stabiliscono e servizi apparentemente inattivi, senza un errore evidente a livello di sistema.

Il comportamento si spiega considerando che il malfunzionamento è confinato allo stack TCP del kernel e non coinvolge l’interfaccia di rete o i driver fisici. La rete continua a trasmettere pacchetti, ma il kernel non è più in grado di gestirli correttamente a livello di sessione.

Scenari e impatto reale del bug in macOS

Il problema confermato da Photon si presenta soprattutto in ambienti con uptime elevato: workstation lasciate accese per settimane, server macOS utilizzati per sviluppo o test, sistemi embedded basati su macOS o configurazioni che evitano riavvii frequenti. In questi casi, il bug può manifestarsi in modo improvviso e senza segnali premonitori.

Una volta raggiunta la soglia temporale, il comportamento si presenta con precisione matematica. Alcuni utenti hanno riportato situazioni in cui il sistema resta apparentemente stabile fino a quel momento, per poi degradare rapidamente sul piano delle comunicazioni.

Va inoltre considerato che il semplice standby o la modalità di sospensione possono influenzare il comportamento: in alcuni scenari il reset parziale dello stack di rete evita temporaneamente la condizione di overflow, rendendo il problema meno evidente e più difficile da correlare all’uptime.

Mitigazioni e possibili interventi

In assenza di una patch ufficiale, l’intervento più ragionevole consiste nel riavvio periodico del sistema prima del raggiungimento della soglia critica. Un intervallo prudenziale di 30-40 giorni riduce il rischio senza impatti significativi sull’operatività.

Un’altra opzione consiste nel monitoraggio attivo dell’uptime e nello scripting di riavvii controllati. Strumenti come launchd o cron possono essere configurati per eseguire operazioni preventive, soprattutto in ambienti automatizzati.

Dal punto di vista architetturale, la soluzione definitiva richiede una modifica al livello del kernel: l’adozione di contatori a 64 bit o la gestione esplicita del rollover nei confronti dei timestamp TCP. Si tratta di interventi non banali, poiché coinvolgono componenti critici dello stack di rete e devono garantire compatibilità con le implementazioni esistenti.