Bug macOS: perde le connessioni TCP dopo 49 giorni di uptime. Il riavvio è l'unica soluzione (aggiornato: 9 aprile 2026, ore 19:11)

Quarantanove giorni, diciassette ore, due minuti e quarantasette secondi. È il tempo esatto dopo il quale un Mac perde silenziosamente la capacità di stabilire nuove connessioni TCP. Nessun errore nei log, nessun avviso a schermo: il ping continua a funzionare, le connessioni già aperte restano attive, ma qualsiasi tentativo di aprirne una nuova fallisce. La causa è un overflow di un intero a 32 bit nel kernel XNU di Apple. L'unico rimedio noto è un riavvio.

Il bug è stato scoperto e documentato dagli ingegneri di Photon, azienda che gestisce una flotta di Mac per monitorare servizi iMessage, e pubblicato sul loro blog nei giorni scorsi.

Il contatore che smette di contare

Al cuore del problema c'è una variabile chiamata tcp_now, un intero senza segno a 32 bit (uint32_t) che il kernel XNU utilizza come orologio interno per lo stack TCP. Il contatore traccia i millisecondi trascorsi dall'ultimo avvio del sistema. Il valore massimo di un uint32_t è 4.294.967.295 - che, espresso in millisecondi, corrisponde esattamente a 49 giorni, 17 ore, 2 minuti e 47 secondi di uptime continuo.

Quando tcp_now raggiunge quel tetto, dovrebbe semplicemente ricominciare da zero. Nel kernel XNU, però, accade qualcosa di diverso: un controllo di monotonicità - con tutta probabilità una guardia aggiunta per prevenire valori incoerenti - interpreta il ritorno a zero come un'anomalia e congela il contatore, e tcp_now smette di avanzare. Da quel momento, ogni timer dello stack TCP che dipende da questa variabile si ferma con esso.

La cascata di guasti

La prima vittima è il meccanismo di pulizia delle connessioni in stato TIME_WAIT. Quando una connessione TCP viene chiusa, il sistema operativo la mantiene in questo stato per un breve periodo - tipicamente qualche minuto - prima di liberare la porta associata. Con tcp_now fermo, il timeout non scade mai, e le connessioni in TIME_WAIT si accumulano senza essere mai rilasciate.

A quel punto le porte effimere - l'intervallo compreso fra 49.152 e 65.535 che il sistema assegna alle connessioni in uscita - si esauriscono progressivamente. Ogni nuova connessione ne consuma una, ma nessuna viene mai liberata . Quando l'ultimo numero di porta disponibile viene occupato, il sistema non è più in grado di stabilire nuove connessioni TCP.

Ciò che rende il bug particolarmente infido è la sua capacità di mascherarsi. ICMP continua a funzionare normalmente, quindi il Mac risponde al ping senza problemi. Le connessioni TCP già attive al momento dell'overflow restano operative. Un amministratore che verifichi la raggiungibilità della macchina con un semplice ping non noterà nulla di strano. Solo i nuovi tentativi di connessione - un browser che prova ad aprire una pagina, un servizio che tenta di connettersi a un database, un'applicazione che cerca di raggiungere un'API remota - falliscono senza spiegazione apparente. Nei log del sistema non compare alcun messaggio d'errore correlato.

Come è stato scoperto

Gli ingegneri di Photon si sono imbattuti nel problema nel modo più frustrante possibile: alcune macchine della loro flotta smettevano inspiegabilmente di accettare nuove connessioni di rete pur rimanendo raggiungibili via ping. Il primo istinto - un riavvio - risolveva il problema, ma non ne spiegava la causa.

La svolta è arrivata correlando i guasti con l'uptime delle macchine coinvolte. Tutti i sistemi colpiti avevano superato la soglia dei 49,7 giorni. Per confermare l'ipotesi, il team ha monitorato altre macchine che si avvicinavano a quel traguardo e osservato il cedimento puntuale allo scoccare del tempo previsto. La riproducibilità è totale: non dipende dal carico, dal tipo di traffico o dalla configurazione di rete. È una bomba a orologeria deterministica.

Chi è davvero a rischio

La maggior parte degli utenti Mac non incontrerà mai questo bug. Apple pubblica aggiornamenti di sicurezza con cadenza regolare, e ogni aggiornamento di sistema richiede un riavvio. Chi mantiene il proprio Mac ragionevolmente aggiornato difficilmente accumula 50 giorni di uptime continuo.

Il problema colpisce un segmento specifico ma non trascurabile: server Mac, macchine di sviluppo sempre accese, sistemi di monitoraggio, build farm e qualsiasi Mac impiegato in un ruolo che presupponga alta disponibilità e uptime prolungato. Esattamente il tipo di scenario in cui ci si aspetterebbe che il sistema operativo fosse solido come una roccia.

Secondo le fonti disponibili, il bug è presente almeno da macOS 10.15 Catalina, rilasciato nel 2019, e il post di Photon è contrassegnato con tag che arrivano fino a macOS Tahoe 26, suggerendo che il problema persista nelle versioni più recenti. Il quadro non è però del tutto limpido: Michael Tsai, sviluppatore noto nella comunità Mac, ha segnalato sul suo blog di aver gestito un Mac server da Catalina fino a Sequoia con mesi di uptime senza mai osservare il problema - anche se non ha ancora aggiornato a Tahoe. La discrepanza non è stata chiarita: è possibile che il bug sia stato introdotto o sia diventato riproducibile in una versione intermedia, oppure che condizioni specifiche di rete ne influenzino la manifestazione.

Un déjà vu a 32 bit

Chi ha qualche anno di esperienza alle spalle riconoscerà subito l'analogia. Windows 95 soffriva di un problema concettualmente identico: un contatore interno a 32 bit che, dopo 49,7 giorni di uptime, causava instabilità o blocco del sistema. C'è dell'ironia nel ritrovare, nel 2026, lo stesso tipo di errore che affliggeva un sistema operativo consumer di trent'anni fa - questa volta in un kernel che Apple mantiene attivamente e che gira su hardware professionale.

Il codice sorgente di XNU è parzialmente disponibile, ma la porzione dello stack TCP coinvolta è evidentemente sfuggita a qualsiasi revisione che ne verificasse il comportamento oltre la soglia dei 32 bit.

Vale anche la pena ricordare che i timestamp TCP di macOS hanno una storia travagliata. Già nel 2008, un thread sulla mailing list di Nmap documentava come macOS 10.5.4 Leopard applicasse un offset casuale ai timestamp TCP all'avvio, rendendo impossibile stimare l'uptime della macchina tramite tecniche di fingerprinting. Un problema diverso, ma che insiste sullo stesso meccanismo sottostante - segno di un'area del codice che evidentemente non ha mai ricevuto l'attenzione che meritava.

Nessuna patch, nessun avviso

Apple non ha rilasciato alcuna correzione per il bug. Non esiste neppure un bollettino di sicurezza o una nota tecnica che ne riconosca l'esistenza. L'unica mitigazione possibile è banale quanto inelegante: riavviare il sistema prima di raggiungere i 49 giorni e 17 ore di uptime. Un cron job, un timer di launchd, un post-it sul monitor - qualsiasi cosa, purché il contatore non arrivi mai a saturazione.

Per chi gestisce flotte di Mac in ambienti di produzione, il consiglio pratico è immediato: implementare un riavvio programmato ben prima della soglia critica. Quaranta giorni è un margine ragionevole. Non è una soluzione, è un cerotto. Ma finché Apple non interverrà sul kernel, è l'unico cerotto disponibile.

Resta sullo sfondo una domanda scomoda sulla robustezza di macOS in scenari server e di lungo uptime. Apple ha storicamente progettato i suoi sistemi operativi per utenti che riavviano con regolarità, e l'ecosistema di aggiornamenti frequenti maschera efficacemente difetti come questo. Nel momento in cui macOS viene impiegato - legittimamente - come piattaforma per servizi continuativi, però, un overflow a 32 bit in una variabile critica dello stack di rete che passa inosservato per sette anni è difficile da giustificare.

Fonti: heise.de, finance.biggo.com, tomshardware.com