Критический баг в ядре XNU грозит полным отказом TCP-соединений. Единственное решение — перезагрузка.
В начале апреля 2026 года исследователи из компании Photon (разработчики платформы для мониторинга iMessage и других сервисов Apple) обнаружили в macOS уязвимость, которая напоминает сюжет научной фантастики — но это реальность. Если ваш Mac работает непрерывно ровно 49 дней, 17 часов, 2 минуты и 47 секунд, его сетевая подсистема TCP/IP полностью отказывает .
Как работает «часовой механизм»
Проблема кроется в глубинах ядра XNU — сердце macOS. Система использует 32-битную переменную tcp_now для отсчёта миллисекунд с момента загрузки. Максимальное значение этого счётчика — 4 294 967 295 миллисекунд, что соответствует упомянутым 49,7 дням
Когда счётчик приближается к пределу, происходит катастрофический сбой логики сравнения временных меток. Функция TSTMP_GEQ(), отвечающая за проверку таймаутов TCP-соединений, начинает работать некорректно. В результате:
- Новые TCP-соединения не устанавливаются (зависают в состоянии SYN_SENT)
- Существующие соединения могут вести себя непредсказуемо
- Сокеты в состоянии TIME_WAIT перестают корректно закрываться
При этом машина продолжает отвечать на ping-запросы, создавая иллюзию работоспособности сети
Почему это важно в 2026 году
В эпоху удалённой работы и облачных сервисов многие компании используют Mac mini и Mac Studio как серверы для CI/CD, мониторинга и автоматизации. Именно в таком сценарии баг и проявился у Photon — их флот машин для мониторинга iMessage внезапно перестал отвечать на сетевые запросы
Сейчас, когда точная природа бага раскрыта, становится ясно: это системная проблема архитектуры, а не случайный глюк. Интересно, что подобные жалобы всплывали на форумах Apple Community ещё в 2019 году (macOS Catalina), но тогда их списывали на локальные проблемы
Технические детали для специалистов
Согласно RFC 7323, при переполнении временной метки TCP должна происходить корректная обработка циклического счётчика. Однако реализация Apple содержит ошибку в макросе TSTMP_GEQ() — при сравнении «замороженного» значения tcp_now (которое перестаёт обновляться при отсутствии TCP-трафика в критический момент) с обёрнутым значением таймера происходит некорректное вычитание
На Hacker News развернулась активная дискуссия: некоторые инженеры отмечают, что баг может проявляться по-разному в зависимости от интенсивности сетевого трафика перед переполнением. Если за 30 секунд до критического момента не было TCP-активности, tcp_now «застревает» и последующие вычисления дают неверные результаты
Кто под угрозой?
Уязвимость затрагивает macOS с SDK 10.0.104 и 10.0.200. Пользователи с uptime более 50 дней (в основном разработчики и системные администраторы, редко перезагружающие рабочие станции) уже подтверждают аномалии: накопление сотен соединений в состоянии TIME_WAIT вместо обычных единиц
Что делать?
Временное решение: регулярная перезагрузка до достижения критического порога.
Перспективы: Photon сообщает о работе над альтернативным патчем, не требующим перезагрузки. Apple, вероятно, выпустит официальное исправление в ближайшем обновлении безопасности
Этот случай напоминает легендарный баг Windows 95, который «падал» через 49,7 дней из-за аналогичного переполнения счётчика. История повторяется — даже в самых надёжных системах.
Источник: Photon Blog