Bom waktu 49 hari yang tersembunyi di macOS — kronologi bug kernel yang membuat jaringan TCP lumpuh total
(photon.codes)Di kernel XNU macOS, ditemukan bug yang membuat jaringan TCP lumpuh total setelah berjalan terus-menerus selama tepat 49 hari 17 jam 2 menit 47 detik. Penyebabnya adalah overflow integer 32-bit pada penghitung timestamp TCP internal kernel (tcp_now). ping tetap merespons, tetapi koneksi TCP baru sama sekali tidak bisa dibuat, dan saat ini satu-satunya solusi adalah reboot.
Bagaimana bug ini ditemukan
Photon mengoperasikan armada server Mac yang memantau status layanan iMessage secara 24/7. Pada 30 Maret 2026, tepat 49,7 hari setelah reboot terakhir, beberapa mesin mulai diam-diam menolak koneksi TCP baru. ping normal, koneksi yang sudah ada tetap bertahan, tetapi semua upaya membuka soket baru gagal.
Untuk memulihkan layanan, tim melakukan reboot lalu memilih dua mesin (A, B) yang akan mencapai ambang yang sama dalam beberapa hari untuk merancang eksperimen langsung.
Mekanisme teknis bug
Penghitung bermasalah tcp_now
tcp_now di kernel XNU adalah integer tak bertanda 32-bit yang menghitung waktu sejak boot dalam satuan milidetik. Nilai maksimum yang dapat direpresentasikan 32-bit adalah 4.294.967.295ms — jika dikonversi, hasilnya tepat 49 hari 17 jam 2 menit 47 detik.
Mengapa penghitungnya "membeku"?
Kode pembaruan tcp_now memiliki guard sederhana untuk "mencegah jam bergerak mundur":
if (tmp < current_tcp_now) {
os_atomic_cmpxchg(&tcp_now, tmp, current_tcp_now, ...);
}
Saat overflow terjadi, current_tcp_now yang baru dihitung kembali berputar ke dekat 0, sedangkan tmp yang lama berada dekat nilai maksimum. Kondisi tmp < current_tcp_now menjadi false selamanya, sehingga tcp_now berhenti pada nilai itu dan tidak pernah berubah lagi. Jam TCP kernel pun berhenti.
Mengapa TIME_WAIT tidak pernah kedaluwarsa
Saat koneksi TCP ditutup, kernel mencatat waktu kedaluwarsa sebagai tcp_now + 30 detik. Garbage collector kemudian memindai secara berkala dan melepaskan koneksi jika tcp_now >= waktu kedaluwarsa. Namun jika tcp_now membeku, kondisi ini tidak akan pernah bernilai true, sehingga koneksi TIME_WAIT tidak pernah dibersihkan.
Hasil eksperimen
Tim mengamati jumlah TIME_WAIT sambil membuat beberapa koneksi TCP berumur pendek per detik selama masing-masing 5 menit sebelum dan sesudah overflow.
| Interval | Status |
|---|---|
| Sebelum overflow | TIME_WAIT stabil di ~200 (kedaluwarsa normal setiap 30 detik) |
| Tepat setelah overflow | Kedaluwarsa berhenti dan TIME_WAIT mulai naik secara monoton |
| 84 detik setelah pembuatan koneksi dihentikan | TIME_WAIT yang seharusnya menjadi 0 justru bertambah (2.828 → 2.837) |
| 9,5 jam setelah overflow | Machine A: 4.888, Machine B: 8.217 — tidak satu pun dibersihkan |
Setelah 9,5 jam, koneksi dalam status SYN_SENT juga menumpuk hingga lebih dari 3.000, dan load average Machine B melonjak sampai 49,74.
Lingkungan yang terdampak
Mac konsumen biasa cenderung reboot sebelum 49 hari karena pembaruan OS, sehingga dampaknya kecil. Namun lingkungan berikut berisiko tinggi:
- Armada server dengan uptime panjang tanpa henti
- Server build macOS CI/CD (Jenkins, GitHub Actions self-hosted runner)
- Workstation Mac Pro (rendering dan kompilasi berjalan lama)
- Mac colocated yang dikelola jarak jauh
- Build farm Mac mini dan infrastruktur pengujian
Penanganan saat ini dan ke depan
Tim saat ini sedang mengembangkan workaround untuk memperbaiki tcp_now yang membeku secara langsung tanpa reboot. Sampai saat itu, hanya ada satu langkah mitigasi sementara:
Jadwalkan reboot sebelum 49 hari 17 jam 2 menit 47 detik.
Bug-bug historis yang serupa
Bug ini termasuk dalam keluarga bug overflow integer yang punya sejarah panjang: crash 49,7 hari di Windows 95/98, masalah tahun 2038 (Y2K38), rollover nomor minggu GPS, dan killscreen level 256 di Pac-Man semuanya berasal dari keluarga yang sama.
Tulisan asli: Photon Blog, 2026.04.07
Belum ada komentar.