Seu Mac Tem um Kill Switch Secreto

Imagine seu Mac, funcionando perfeitamente por semanas a fio, de repente perdendo toda a conectividade de rede. Não devido a uma falha passageira de Wi-Fi ou problema de roteador, mas a um colapso interno que deixa sua máquina isolada. Isso não é um medo hipotético; é uma bomba-relógio enterrada profundamente no macOS, pronta para atacar após um uptime prolongado. Precisamente 49 dias, 17 horas e 2 minutos de operação contínua tornarão todo o stack de rede da sua máquina completamente inútil, transformando uma poderosa estação de trabalho em um tijolo inerte e desconectado da internet. Seu Mac permanece ligado, mas seu mundo digital encolhe para nada.

Isso não é um mito urbano obscuro ou um bug raro e irrepetível; é uma falha de nível de kernel totalmente verificada. Engenheiros da startup Photon recentemente descobriram e documentaram meticulosamente esta vulnerabilidade crítica na implementação TCP da Apple. Sua análise detalhada expõe uma falha fundamental na forma como o macOS lida com os timestamps internos do sistema, especificamente um inteiro sem sinal de 32 bits chamado `tcp_now`. A equipe da Photon, encontrando o problema repetidamente em sua frota de Macs usados para monitorar serviços iMessage, reproduziu meticulosamente o bug em várias máquinas. Eles então rastrearam cuidadosamente sua origem até um erro específico de lógica de comparação dentro do próprio XNU kernel, o componente central do sistema operacional da Apple.

A descoberta desta falha precisa e acionada por tempo oferece um lembrete sóbrio da fragilidade inerente mesmo nos sistemas operacionais modernos mais sofisticados. Em 2026, um simples contador, operando no cerne de um sistema, ainda pode colocar um Mac de joelhos, impactando tudo, desde a navegação web e e-mail rotineiros até tarefas críticas de desenvolvimento como `git push`. Isso destaca uma vulnerabilidade significativa que permaneceu oculta por anos, confirmada para afetar o macOS 10.15 (Catalina) e todas as versões subsequentes. O fato de tal falha fundamental ter persistido ressalta a imensa complexidade de manter software robusto e de alto desempenho em escala.

Como um temporizador tão preciso aciona uma falha de rede catastrófica, e por que um sistema geralmente projetado para estabilidade de repente se desfaz? O culpado reside em um inteiro sem sinal de 32 bits e seu inevitável overflow, combinado com um bug crucial na lógica de comparação. Este artigo irá detalhar exatamente como essa aparente pequena falha aritmética no código da Apple leva ao esgotamento completo das portas efêmeras disponíveis, prejudicando a capacidade do seu Mac de estabelecer novas conexões TCP. Vamos aprofundar na mecânica específica da variável `tcp_now`, explorar o TCP reaper confuso do kernel e revelar a sequência precisa de eventos que transforma o uptime contínuo em um penhasco digital crítico para o seu Mac, exigindo nada menos que uma reinicialização completa do sistema para restaurar a funcionalidade.

O problema central de rede do seu Mac reside profundamente no kernel do macOS, especificamente com uma variável chamada `TCP_NOW`. Este é um inteiro sem sinal de 32 bits meticulosamente projetado para rastrear milissegundos desde a última inicialização do sistema. Ele conta silenciosamente, marcando cada momento em que seu Mac permanece ligado, um temporizador fundamental para operações de rede.

Um inteiro sem sinal de 32 bits, por sua natureza, possui uma capacidade finita. Ele pode armazenar valores de zero até 2^32 - 1. Para `TCP_NOW`, isso se traduz em uma contagem máxima de 4.294.967.295 milissegundos. Uma vez atingido esse limite numérico, a variável não pode mais incrementar, iniciando um evento computacional fundamental conhecido como um estouro de inteiro.

Este estouro ocorre precisamente após 49 dias, 17 horas, 2 minutos e 47,296 segundos de tempo de atividade contínua. Neste exato momento, o contador `TCP_NOW` realiza um "wraparound" (reinicialização). Ele atinge seu valor máximo e então, como um hodômetro que passa do seu dígito mais alto, ele reinicia para zero. Este rollover é uma característica previsível e inerente da aritmética de inteiros de tamanho fixo.

Tais reinicializações de contador são um comportamento normal e esperado na computação, e a maioria dos sistemas operacionais são projetados de forma robusta para lidar com eles sem problemas. Geralmente, os sistemas simplesmente ajustam sua lógica interna para considerar a reinicialização, muitas vezes comparando valores enquanto reconhecem a possibilidade de um wraparound. No entanto, a implementação da Apple de TCP timestamps no macOS contém uma falha crítica na forma como processa este evento específico.

Engenheiros da Photon descobriram que a lógica de comparação do kernel falha em interpretar corretamente o valor `TCP_NOW` reiniciado após o wraparound. Essa má interpretação efetivamente congela o relógio interno de timestamp TCP, que é crucial para gerenciar o ciclo de vida das conexões de rede. Em vez de se adaptar, o sistema trata o contador reiniciado como uma anomalia.

Isso impede a limpeza necessária das conexões `TIME_WAIT`, levando a um esgotamento gradual das portas efêmeras—os identificadores temporários que o seu Mac usa para solicitações de rede de saída. Esta falha, enterrada no kernel, transforma um comportamento rotineiro de inteiro em uma potente vulnerabilidade do sistema, incapacitando, em última instância, a capacidade do seu Mac de estabelecer novas conexões de rede.

Exatamente 49 dias, 17 horas, 2 minutos e 47 segundos de operação contínua, o inteiro sem sinal de 32 bits do kernel do macOS, `TCP_NOW`, atinge seu valor máximo. Isso representa 2^32 milissegundos de tempo de atividade. Neste momento preciso, o contador sofre um estouro de inteiro, retornando a zero. Embora a maioria dos sistemas operacionais modernos lide graciosamente com tais reinicializações, o macOS sofre de uma falha fundamental em sua lógica de comparação.

A implementação defeituosa do kernel de TCP timestamps interpreta erroneamente esta reinicialização. Em vez de reconhecer o wraparound e continuar a progressão do timestamp, o relógio interno de timestamp TCP efetivamente congela. Este erro crítico prepara o terreno para uma falha em cascata dentro da pilha de rede.

Central para esta falha está o TCP reaper, um processo vital do kernel responsável pela limpeza de conexões de rede fechadas. Normalmente, o reaper purga eficientemente as conexões que permanecem no estado TIME_WAIT, liberando recursos do sistema e portas efêmeras. Essas conexões permanecem brevemente após o fechamento para garantir que todos os segmentos de dados sejam transmitidos de forma confiável e para evitar problemas com pacotes atrasados de conexões anteriores.

No entanto, o timestamp congelado confunde completamente o reaper. Ele compara continuamente os timestamps dessas conexões `TIME_WAIT` fechadas com um relógio de sistema estático e não avançante. Logicamente, o reaper percebe essas conexões como perpetuamente novas ou recentemente ativas, nunca atingindo seu ponto de expiração. Ele acredita que elas devem permanecer abertas, recusando-se a encerrá-las.

Consequentemente, as conexões `TIME_WAIT` acumulam-se indefinidamente dentro do kernel, nunca liberando suas portas efêmeras associadas. Isso não é uma falha súbita do sistema, mas sim uma forma lenta e insidiosa de paralisia. O Mac esgota gradualmente seu pool finito de portas efêmeras, tipicamente em torno de 16.384.

Uma vez que todas as portas efêmeras são consumidas, o Mac não consegue mais estabelecer novas conexões TCP de saída. Embora as sessões de rede existentes possam persistir, qualquer tentativa de iniciar uma nova comunicação — seja navegando na web, verificando e-mails ou executando um `git push` — simplesmente travará indefinidamente. Essa falha silenciosa e insidiosa torna as capacidades de rede do sistema inúteis, tudo devido a um único erro de lógica negligenciado. Engenheiros da Photon descobriram e documentaram extensivamente este mecanismo preciso; para mais detalhes técnicos, leia We Found a Ticking Time Bomb in macOS TCP Networking - It Detonates After Exactly 49 Days - Photon.

Estabelecer uma nova conexão de rede, seja carregando uma página da web, enviando um e-mail ou realizando um `git push`, depende fundamentalmente de portas efêmeras. Esses números de porta temporários, atribuídos dinamicamente pelo sistema operacional, atuam como identificadores únicos para o lado do cliente de uma conexão TCP de saída. Sem uma porta efêmera disponível, seu Mac simplesmente não consegue iniciar contato com nenhum serviço externo, isolando-o efetivamente da internet.

Normalmente, uma vez que uma conexão TCP se fecha, ela entra em um estado `TIME_WAIT` por um breve e crítico período. Isso garante que todos os pacotes sejam entregues de forma confiável e previne problemas com segmentos atrasados de conexões antigas. Um processo de kernel dedicado, frequentemente apelidado de TCP reaper, então limpa diligentemente essas conexões, liberando suas portas associadas para reutilização. Este ciclo eficiente mantém o conjunto de portas disponíveis pronto para novas solicitações.

No entanto, o bug de timestamp `TCP_NOW` paralisa fundamentalmente este mecanismo crítico de limpeza. Com o relógio de timestamp TCP interno congelado, o reaper do kernel percebe incorretamente todas as conexões `TIME_WAIT` como perpetuamente ativas; ele simplesmente se recusa a excluí-las. Isso cria um vazamento de recursos grave e insidioso, pois cada conexão fechada continua a ocupar uma das 16.384 portas efêmeras limitadas do sistema, nunca a liberando de volta para o conjunto.

Considere um restaurante movimentado onde as mesas sujas nunca são limpas depois que os clientes terminam suas refeições. Novos clientes chegam, mas com cada mesa ocupada por clientes demorados e não atendidos, nenhum novo cliente pode ser sentado. Apesar de aparentar estar aberto e funcional, o restaurante eventualmente se torna completamente inutilizável para novos negócios, espelhando as capacidades de rede do seu Mac.

Este esgotamento de portas não é um evento instantâneo na marca de 49 dias, 17 horas e 2 minutos. Em vez disso, ele se manifesta como um aperto lento, consumindo gradualmente as portas disponíveis ao longo de algumas horas. Inicialmente, as operações de rede podem ficar lentas, os aplicativos podem travar intermitentemente ou as solicitações de busca podem falhar. Em última análise, seu Mac ficará sem portas completamente, tornando todas as novas conexões TCP impossíveis e cortando efetivamente sua conexão com o mundo digital.

Os usuários encontram uma cascata desconcertante de falhas de rede depois que seu Mac ultrapassa o limite de 49 dias de tempo de atividade. Navegadores da web param completamente, exibindo spinners de carregamento persistentes ou erros de "conexão esgotada". Desenvolvedores encontram comandos `git push` travando indefinidamente, e chamadas de API críticas de aplicativos simplesmente falham ao conectar, muitas vezes retornando erros de rede genericamente frustrantes. Isso não é uma interrupção completa da rede; é uma falha seletiva e insidiosa.

Aumentando a confusão, as conexões de rede de longa duração frequentemente permanecem operacionais. Uma sessão SSH ativa para um servidor remoto pode continuar a funcionar perfeitamente, permitindo que comandos sejam executados e a saída seja transmitida de volta sem interrupção. Este contraste gritante entre conexões existentes funcionando e tentativas de novas conexões completamente falhas torna o diagnóstico inicial incrivelmente difícil para usuários desavisados e profissionais de TI.

Ainda mais enganador, diagnósticos básicos de rede como o comando `ping` frequentemente relatam conectividade total, recebendo respostas de hosts remotos como esperado. Isso acontece porque o `ping` depende do ICMP (Internet Control Message Protocol), uma camada diferente da pilha de rede, ignorando completamente a camada TCP problemática. Um comando `ping` funcionando sinaliza incorretamente uma rede saudável, enviando os solucionadores de problemas por caminhos improdutivos.

Esses sintomas díspares — novas conexões TCP falhando, conexões TCP existentes persistindo e ICMP permanecendo funcional — criam uma tempestade perfeita de frustração diagnóstica. Sem conhecimento prévio do estouro do contador TCP_NOW e seu impacto específico no ephemeral port exhaustion, identificar a causa raiz torna-se uma tarefa quase impossível. A única solução imediata, embora temporária, é uma reinicialização completa do sistema, redefinindo o relógio interno e restaurando a funcionalidade da rede.

Engenheiros da Photon, uma startup de infraestrutura de AI e ferramentas para desenvolvedores, foram os primeiros a identificar a falha de rede elusiva do macOS. Eles gerenciavam uma frota significativa de Macs, especificamente para a exigente tarefa de monitoramento do iMessage. Nessas máquinas, eles observaram um padrão desconcertante e correlacionado ao tempo: após aproximadamente 49 dias de tempo de atividade contínuo, a funcionalidade da rede degradava consistentemente e, em seguida, falhava completamente. Essa anomalia não era aleatória; ela ocorria com uma previsibilidade frustrante.

Sua jornada de depuração foi rigorosa, indo além dos sintomas superficiais. A equipe da Photon rastreou sistematicamente o problema, aprofundando-se no código-fonte do kernel XNU. Eles descobriram meticulosamente a lógica de comparação falha ligada ao inteiro sem sinal de 32 bits `TCP_NOW`, identificando precisamente onde o relógio de timestamp TCP efetivamente congelava após seu estouro. Essa análise profunda confirmou a origem do bug no nível do kernel, bem distante das aplicações do usuário.

A subsequente divulgação pública da Photon provou ser crucial para alertar a comunidade tecnológica mais ampla. Sua postagem detalhada no blog técnico, lançada no início de 2026, expôs a mecânica deste bug insidioso. Essa transparência forneceu uma compreensão clara e acionável do porquê a pilha de rede de um Mac se autodestruiria após 49,7 dias. Usuários da Apple e administradores de sistema finalmente tinham uma explicação para interrupções de rede anteriormente inexplicáveis.

Crucialmente, o trabalho da Photon incluiu um reproducible test case. Isso permitiu que outros desenvolvedores e administradores de sistema verificassem independentemente o bug, confirmando seu impacto generalizado no macOS 10.15 (Catalina) e versões subsequentes. Sua análise abrangente desmistificou o problema, movendo-o de uma frustração anedótica para uma falha crítica e bem compreendida no sistema operacional da Apple. Para mais informações sobre os detalhes técnicos do bug e suas implicações mais amplas, macOS has a 49.7-day networking time bomb built in that only a reboot fixes — comparison operation on unreliable time value stops machines dead in their tracks | Tom's Hardware oferece leitura adicional. Este relato detalhado destacou a vulnerabilidade inerente até mesmo a um simples estouro de inteiro de 32 bits.

Notavelmente, o bug descoberto pelos engenheiros da Photon no macOS ecoa uma falha notória do passado da computação. O Windows 95 e 98 sofreram notoriamente de uma falha de uptime semelhante de 49.7 dias, também enraizada em um estouro de contador de 32 bits. Este bug mais antigo, como o problema atual do Mac, congelaria o sistema depois que seu contador interno de milissegundos desse a volta, tornando o OS sem resposta.

Estes incidentes destacam um desafio persistente e fundamental na ciência da computação: o tratamento robusto do tempo. O ato aparentemente simples de contar o tempo tem repetidamente enganado até mesmo os desenvolvedores mais experientes. Lembre-se do pânico global em torno do problema do Y2K, onde uma representação de ano de dois dígitos ameaçou falhas generalizadas de sistemas na virada do milênio.

Hoje, o problema do Ano 2038 paira sobre os sistemas Unix de 32 bits, onde o inteiro `time_t`, que conta os segundos desde 1º de janeiro de 1970, irá estourar. Esta futura crise poderá causar erros generalizados relacionados a datas, novamente devido às limitações de um inteiro de 32 bits. O atual dilema do seu Mac serve como um lembrete claro e moderno dessas vulnerabilidades históricas e iminentes baseadas no tempo.

Apesar de décadas de aprendizado com esses eventos, a mesma classe de bugs continua a surgir. A implementação da Apple de `TCP_NOW` como um inteiro sem sinal de 32 bits, sem tratamento robusto de rollover, demonstra esse padrão cíclico. Os desenvolvedores devem gerenciar meticulosamente os limites de inteiros e evitar números mágicos em componentes críticos do kernel.

Isso não é meramente uma falha de software; representa uma lição profunda sobre a fragilidade das suposições no design de sistemas. O "kill switch" silencioso do seu Mac, como seus predecessores, ressalta a necessidade absoluta de antecipar estouros de contador e implementar mecanismos de segurança, particularmente em códigos que sustentam a funcionalidade central de rede. A análise da Better Stack e a descoberta da Photon reforçam este princípio crucial de engenharia.

Usuários médios de Mac podem, em grande parte, desconsiderar este bug crítico de rede. A maioria dos indivíduos desliga ou reinicia suas máquinas frequentemente para atualizações de software, estabilidade do sistema ou até mesmo desligamentos diários. Essas reinicializações rotineiras efetivamente redefinem o contador TCP_NOW, impedindo que ele se aproxime do limite de uptime de 49 dias, 17 horas e 2 minutos, onde o problema se manifesta.

No entanto, a ameaça é grande para demografias profissionais específicas. Desenvolvedores, cientistas de dados e administradores de TI que gerenciam extensas frotas de Mac representam os grupos de alto risco. Esses profissionais frequentemente configuram Macs como servidores headless, plataformas dedicadas de continuous integration, máquinas de build ou nós de coleta de dados de longo prazo, exigindo operação ininterrupta por semanas ou meses.

Para esses casos de uso especializados, manter um uptime estendido não é meramente um distintivo de honra; é um requisito operacional fundamental. O serviço ininterrupto é primordial para tarefas como compilar grandes bases de código, executar extensas suítes de teste, processar simulações científicas ou monitorar infraestruturas críticas, onde qualquer tempo de inatividade se traduz diretamente em perda de produtividade e atrasos de projeto. A paralisia inesperada da rede após 49 dias pode interromper severamente os pipelines de desenvolvimento ou comprometer a integridade dos dados.

Para mitigar este assassino silencioso, o monitoramento proativo do uptime do sistema é indispensável para os grupos afetados. Os administradores devem implementar mecanismos robustos de alerta, talvez scripts personalizados ou soluções integradas de plataformas como Better Stack, para rastrear `sysctl kern.boottime`. Configure esses sistemas para emitir avisos urgentes bem antes do "penhasco digital" de 49 dias.

Agendar reinicializações regulares e controladas é atualmente a única medida preventiva confiável. Essas interrupções planejadas, executadas antes da marca crítica de 49 dias, 17 horas e 2 minutos, garantem que o contador `TCP_NOW` seja redefinido, evitando o esgotamento de portas e o subsequente congelamento da rede. Esta estratégia permite que a infraestrutura crítica de Mac continue funcionando sem interrupções inesperadas.

A única correção universalmente disponível para o colapso de rede de 49,7 dias do macOS permanece surpreendentemente simples: uma reinicialização. Reiniciar a máquina efetivamente redefine o contador `TCP_NOW`, limpando a memória do sistema das conexões TCP acumuladas e não liberadas e restaurando o relógio de timestamp TCP para seu estado correto e monotônico. Esta solução antiga restaura instantaneamente a funcionalidade total da rede, permitindo que a pilha TCP processe novas conexões e gerencie portas efêmeras corretamente por mais 49 dias, 17 horas e 2 minutos.

Departamentos de TI e usuários que gerenciam sistemas Mac sempre ligados, especialmente aqueles em funções de servidor ou ambientes de monitoramento contínuo, devem implementar uma política de reinicialização proativa. Agendar reinicializações pelo menos a cada 45 dias evita que as máquinas se aproximem do limite crítico de 49 dias. Esta manutenção de rotina, embora aparentemente básica, prova ser essencial para evitar os sintomas frustrantes e difíceis de diagnosticar de esgotamento de portas e garante a disponibilidade ininterrupta da rede para serviços críticos. Não fazê-lo pode levar a interrupções operacionais significativas e perda de produtividade.

Para sistemas altamente especializados e de missão crítica onde reinicializações simplesmente não são uma opção, soluções avançadas já estão sendo exploradas. Engenheiros da Photon, a empresa que meticulosamente descobriu e documentou este bug, estão supostamente desenvolvendo um sofisticado live kernel patch. Esta solução altamente técnica visaria manipular o estado interno do kernel — especificamente a variável `TCP_NOW` e a lógica de comparação relacionada — sem exigir uma reinicialização completa do sistema. Tal capacidade oferece uma tábua de salvação vital para infraestruturas que absolutamente não podem tolerar tempo de inatividade, como a frota de monitoramento do iMessage onde a Photon observou o problema pela primeira vez.

Os usuários podem monitorar facilmente o uptime atual do seu Mac diretamente do Terminal. Basta abrir o aplicativo Terminal (encontrado em Aplicativos/Utilitários), digitar `uptime` e pressionar Enter. A saída exibirá há quanto tempo o sistema está em execução desde a última inicialização, geralmente mostrando dias, horas e minutos. Isso oferece uma maneira direta de acompanhar sua proximidade do limite de 49 dias e planejar quaisquer reinicializações necessárias com bastante antecedência.

Embora a Apple ainda não tenha lançado um patch oficial, a vigilância e as reinicializações regulares continuam sendo a principal defesa contra este assassino silencioso de rede. Esta situação ressalta que mesmo sistemas operacionais modernos podem abrigar falhas fundamentais de baixo nível com impacto significativo no mundo real. Para detalhes mais abrangentes sobre este problema intrincado, incluindo seus paralelos históricos e a análise aprofundada da Photon, você pode ler sobre o Bizarre bug in macOS is a 'ticking time bomb' that takes out networking capabilities if a Mac is left on for too long | TechRadar.

A Apple, sem dúvida, abordará esta questão crítica. Espere um patch em nível de kernel em uma próxima atualização de software do macOS, visando diretamente a lógica de comparação defeituosa e o tratamento de inteiros `TCP_NOW`. Esta correção provavelmente será lançada através de atualizações de software padrão para todas as versões afetadas do macOS, de Catalina em diante.

A descoberta da Photon desfere um golpe significativo na reputação cuidadosamente cultivada da Apple de construir sistemas que 'simplesmente funcionam'. Usuários profissionais e corporativos, que frequentemente mantêm frotas de Macs para operações críticas, sentirão esse impacto de forma mais aguda. Uma falha fundamental de rede, tornando um Mac inútil sem um reboot, corrói a confiança na estabilidade de nível empresarial da Apple.

Este não é um bug menor; é um abismo digital que mina a confiabilidade esperada de um sistema operacional moderno. Para empresas como a Photon, que utilizam Macs para serviços essenciais como o monitoramento de iMessage, o limite de uptime de 49 dias é inaceitável. A Apple se orgulha da robustez do sistema, tornando esta falha central uma falha visível em sua confiabilidade percebida.

Como um bug tão fundamental pôde persistir por tanto tempo em múltiplas iterações do macOS? A maioria dos usuários de Mac consumidores simplesmente não mantém suas máquinas funcionando continuamente por 49 dias, 17 horas e 2 minutos. Eles frequentemente reiniciam para atualizações do macOS, instalações de aplicativos ou manutenção geral, redefinindo inadvertidamente o contador `TCP_NOW`.

Este padrão sugere um possível ponto cego nas metodologias de garantia de qualidade e teste da Apple. Os pipelines de QA padrão provavelmente se concentram em ciclos de usuário típicos, perdendo os casos extremos de uptime que as implantações corporativas, como as da Photon, naturalmente encontram. Testes automatizados podem não visar especificamente esses estados de sistema de longa duração, permitindo que este assassino silencioso permaneça indetectável por anos.

A revelação da Photon serve como um lembrete sério para toda a indústria de tecnologia. Mesmo em 2026, com hardware sofisticado e complexas pilhas de software, um único inteiro sem sinal de 32 bits ainda pode paralisar o sistema operacional de um gigante da tecnologia moderno. Esta falha fundamental ecoa os infames bugs de crash de 49,7 dias no Windows 95 e Windows 98, provando que alguns desafios de baixo nível permanecem atemporais. Isso ressalta a vigilância constante necessária no desenvolvimento de kernel, onde detalhes aparentemente menores podem se transformar em falhas catastróficas.

O que é o bug de rede de 49 dias do macOS?

É um bug de nível de kernel onde um timer de 32 bits transborda após aproximadamente 49,7 dias de uptime. Isso congela os timestamps TCP e, eventualmente, impede que novas conexões de rede sejam estabelecidas.

Como sei se meu Mac foi afetado?

Se o seu Mac estiver funcionando continuamente por mais de 49 dias e, de repente, não conseguir acessar sites ou outros serviços de rede, você provavelmente foi afetado. Você pode verificar o uptime do seu sistema no aplicativo Terminal com o comando 'uptime'.

Qual é a correção permanente para este bug do Mac?

A única solução permanente é um patch de kernel oficial da Apple em uma futura atualização do macOS. A correção atual e única em nível de usuário é reiniciar seu Mac pelo menos uma vez a cada 49 dias para redefinir o timer interno.

Este bug afeta todos os usuários de Mac?

Ele afeta principalmente usuários que exigem longos uptimes, como desenvolvedores, pesquisadores ou aqueles que usam Macs como servidores. A maioria dos usuários casuais que desligam ou reiniciam regularmente para atualizações nunca o encontrará.