Seu Mac tem uma bomba-relógio que trava a rede depois de 49 dias ligado

Um bug no kernel do macOS mata todas as conexões de rede do seu Mac depois de exatamente 49 dias, 17 horas, 2 minutos e 47 segundos ligado sem reiniciar. O computador continua funcionando. O ping continua respondendo. Mas qualquer tentativa de abrir uma conexão TCP nova, seja SSH, navegador, API ou banco de dados, simplesmente falha. E o motivo é um bug macOS 49 dias que a Apple ainda não corrigiu.

O problema foi descoberto pela Photon, uma empresa que opera uma frota de Macs para monitorar serviços do iMessage. Eles notaram que certas máquinas paravam de aceitar conexões novas enquanto continuavam respondendo a ping normalmente. Ao cruzar os dados de uptime de todas as máquinas, identificaram o limite exato: 49,7 dias.

O que acontece por dentro

O culpado é uma variável chamada tcp_now no código-fonte do XNU, o kernel do macOS. Ela é um inteiro de 32 bits sem sinal (um uint32_t, pra quem programa) que conta os milissegundos desde o boot do sistema, do ponto de vista da pilha TCP.

Um uint32_t armazena no máximo 4.294.967.295. Em milissegundos, isso dá exatamente 49,71 dias. Quando o uptime ultrapassa esse limite, o valor retornado pela função microuptime() excede o que cabe em 32 bits. Na hora de converter pra uint32_t, o número “dá a volta” e recomeça do zero.

Aqui é onde a Apple errou. O código tem uma proteção de monotonicidade, um mecanismo que impede o relógio de parecer “voltar no tempo”. Essa proteção lê o valor zerado, compara com o valor anterior (que estava perto do máximo), conclui que o tempo “regrediu” e congela a variável tcp_now no valor máximo. Pra sempre.

Com tcp_now congelado, o coletor de lixo de conexões TCP em estado TIME_WAIT (conexões fechadas que o sistema mantém por 30 segundos pra lidar com pacotes atrasados) nunca consegue limpar nada. A comparação de timestamps falha permanentemente. As cerca de 16 mil portas efêmeras do sistema (range 49152-65535) vão enchendo aos poucos com conexões fantasma. Quando todas estão ocupadas, nenhuma conexão TCP nova pode ser aberta.

O log do kernel registra a mensagem comparison operation on unreliable time value, que é o próprio código da Apple detectando a inconsistência antes de tomar a decisão errada.

O déjà vu do Windows 95

Se o número 49,7 dias pareceu familiar, não é coincidência. O Windows 95 tinha exatamente o mesmo bug. O driver VTDAPI.VXD usava um inteiro de 32 bits pra contar milissegundos de uptime. Depois de 49,7 dias, o contador estourava e o sistema travava. Mesmo tipo de variável, mesma unidade de medida, mesmo limite matemático.

Não é um caso isolado. O Boeing 787 tem uma exigência de manutenção que obriga o reinício dos sistemas a cada 51 dias por causa de um overflow parecido. O Arduino sofre do mesmo problema com a função millis(). E em 2038 vamos lidar com o estouro do timestamp Unix de 32 bits, que é primo de primeiro grau desse bug.

A diferença é que em 1995 a Microsoft levou meses pra corrigir e todo mundo achou compreensível. Em 2026, a Apple, que posiciona o Mac como plataforma profissional e de servidor, repetir a mesma classe de erro é no mínimo constrangedor.

Quem é afetado

A maioria dos usuários comuns não vai encontrar esse bug. Se você reinicia o Mac pra instalar atualizações, coloca pra dormir à noite ou desliga de vez em quando, o contador nunca chega a 49 dias.

O problema real é pra quem usa Mac como servidor ou infraestrutura sempre ligada. Mac Minis rodando como CI/CD runners (GitHub Actions, GitLab CI, Buildkite). Mac Pros usados como servidores de build. Máquinas de monitoramento que ficam ligadas 24/7. Qualquer Mac que rode sem sleep e sem reiniciar por mais de sete semanas está na mira.

A falha é silenciosa. O computador parece saudável. O ping funciona. Os processos rodam. Até que alguém tenta abrir uma conexão nova e nada acontece. Quem já teve um servidor “misteriosamente” parando de responder pode muito bem ter encontrado esse bug sem saber.

A (não) resposta da Apple

Até o momento, a Apple não se pronunciou. Não há CVE publicado. Não há patch disponível. Não há menção nas notas de atualização do macOS. O Six Colors notou que “isso é algo que a Apple deveria estar trabalhando pra resolver”, o que é um jeito educado de dizer que o silêncio é inaceitável.

A Photon, que descobriu o bug, está desenvolvendo uma correção por conta própria. Enquanto isso, a recomendação deles é agendar reinícios preventivos antes da marca de 40 dias de uptime. Você pode monitorar conexões em TIME_WAIT com o comando netstat -an | grep TIME_WAIT pra identificar se o problema está começando a se manifestar.

Um bug de 1995 em 2026

O código-fonte do XNU é público. O bug viola o RFC 7323, que especifica como lidar com o wraparound de timestamps TCP. A solução seria trocar o uint32_t por um uint64_t (um inteiro de 64 bits, que só estouraria depois de 584 milhões de anos) ou simplesmente tratar o overflow corretamente na proteção de monotonicidade.

Qualquer desenvolvedor que já lidou com contadores de tempo em sistemas embarcados sabe que overflow de 32 bits é o primeiro item da lista de coisas que podem dar errado. É computação 101. O fato de isso estar no kernel de um sistema operacional usado em 2026 diz algo sobre o nível de atenção que a pilha de rede do macOS recebe comparada ao marketing do produto.