Geliştirici, hatalı ürün yazılımı EOL olan kendi TP-Link EAP770'si için kernel açığı yazdı

İndirmelerini kendi bozan bir access point

dfb.sh adresindeki geliştiricinin blogunda yayımlanan ve Hacker News'in ana sayfasına çıkan detaylı yazıya göre hikâye, Ağustos 2023'te Qualcomm IPQ9574 SoC üzerinde çalışan ve Linux 5.4.164 kullanan bir Wi-Fi 7 access point olan TP-Link EAP770 v1'in satın alınmasıyla başladı. Dizüstü bilgisayara yapılan Wi-Fi aktarımları birkaç GiB'yi aşan dosyalarda başarısız olmaya başladı ve SSH MAC hataları bildiriyordu. Wireshark sıfır hatalı checksum ve sıfır yeniden iletim gösterdiği, rastgele baytlardan oluşan tek bir UDP akışı da sorunsuz geçtiği için geliştirici başlangıçta rsync ve SSH'yi suçladı, bir yeniden deneme sarmalayıcısı yazdı ve yoluna devam etti.

Sonradan tesadüfen bir çözüm ortaya çıktı: Tailscale trafiği ev ağı içinde taşındığında hatalar fiilen kayboldu. WireGuard kimlik doğrulaması başarısız olan her paketi düşürdüğü için tünelin içindeki TCP bağlantısı bozulan veriyi yeniden iletti — bu da hatayı onarmak yerine maskelemiş oldu.

Çarpıcı bir ayrıntı: Wi-Fi 7 standardı Eylül 2024'te finalize edildi, cihazda Wi-Fi Alliance sertifikası yok ve AP hiçbir zaman kutusundan çıktığı sürümün ötesinde bir ürün yazılımı güncellemesi almadı.

Kutusundan çıkarılmadan EOL olması

Haziran 2025'te, evdeki her şeyin güncelleme alırken AP'nin orijinal ürün yazılımında kalmasını fark eden geliştirici TP-Link ile iletişime geçti. Satıcının web sitesi yalnızca v2 donanımı için ürün yazılımı sunuyordu, destek başlangıçta v1'i veritabanında bulamadı ve cihazın ile kutunun fotoğraflarını istedi, ardından EAP770 Version 1'in artık ürün yazılımı güncellemeleriyle desteklenmeyen bir end-of-life ürün olduğunu doğruladı. v2 ürün yazılımı farklı donanımı hedefliyor, kardeş ürün EAP773'nin imajı cihaz tarafından reddedildi ve yeni v2 sürümleri şifreli — yani yamalanmış bir cihaza giden meşru bir yol yoktu.

Geçerli checksum'lı 64 hatalı bayt

Bir LLM ve BPF probeleriyla desteklenen 2026'daki yenilenmiş hata ayıklama çabası, kesin kanıtı ortaya çıkardı: başarısız bir HTTPS indirmesinin tcpdump kaydı, içinde 64 ardışık hatalı bayt barındıran 1440 baytlık bir TCP segmenti gösterdi — üstelik geçerli bir TCP checksum'ıyla. TcpInCsumErrors sıfırda kaldı; yani yoldaki bir şey payload'u bozmuş ve sonra checksum'ı yeniden hesaplamıştı.

Kablolu bir makine ile Wi-Fi dizüstü bilgisayar arasındaki ham TCP testleri, bozulmanın yalnızca birkaç eşzamanlı TCP akışında, yalnızca LAN'dan Wi-Fi yönünde ortaya çıktığını ve 8192 MiB boyunca sıfırlarla başlayan üç hatalı 64 baytlık blok ürettiğini gösterdi. Altmış dört bayt, IPQ9574'nün çekirdeklerinde bir cache line boyutudur; bu da tek bir bitin dönmesinden çok bir cache ya da DMA hatasına işaret eder. Dizüstünün Wi-Fi kartını değiştirmek yardımcı olmadı, kablolu istemciler temizdi ve hatalı çerçevelerdeki CCMP MIC sağlamdı. Geriye AP'nin içindeki köprü kalıyordu; orada hem köprülü trafiği hızlandıran hem de checksum'ları yeniden yazan tek bileşen ise Qualcomm'un SFE/PPE offload'ıydı. Saat 11:00 civarındaki günlük kopmalar ise dizüstünün Wi-Fi kartı ürün yazılımındaki ayrı bir hata çıktı.

Root gerektiren iki sıfır

Sürücü kaynak kodunu okumak bir çözüm önerdi: offload'ı devre dışı bırakmak için /sys/sfe/l2_feature ve /sys/sfe/ppe_rfs_feature dosyalarına 0 yazmak. Ancak bu sysfs dosyaları yalnızca root tarafından erişilebilir, TP-Link'in SSH kabuğu hiçbir capability olmadan uid 1 olarak çalışıyor ve GUI'de ilgili bir ayar yok. Yamalanabilir bir ürün yazılımı imajı olmadığı ve flash clip peşinde koşup cihazı brick etme riskini almak istemediği için geliştirici, tek yolun kernel olduğuna karar verdi.

TP-Link'in kullanıcı alanı gerçekten sağlamlaştırılmıştı — her yerde beyaz listeler, minimum sayıda modül ve satıcının kendi ikili dosyalarında hiçbir saldırı vektörü yoktu. Bunun üzerine geliştirici, kamu kaynaklarına dayanarak, ayrıcalıksız bir user namespace'ten erişilebilen ve heap overflow'a yol açan kernel'deki legacy_parse_param() içindeki integer underflow zafiyeti CVE-2022-0185'den bir zincir kurdu ve bunu pipe-buffer manipülasyonuyla serbest yazma (arbitrary write) yeteneğine dönüştürdü. Exploit, AP'yi çalışır halde bırakmak zorundaydı; çünkü bozuk offload yeniden başlatma sonrası geri geliyordu ve overflow, kernel'i ikinci denemenin panic ile sonuçlanacağı bir duruma sokuyordu: her açılışta tek atış hakkı.

Geliştirme süreci, EAP783'ün yayımlanmış GPL kaynaklarından oluşturulan ve kernel yapılandırması AP'den yalnızca üç kozmetik satırla ayrışan bir QEMU ortamında yürütüldü. AP'nin kernel'i KASLR içermiyor ama kallsyms değerleri sıfırlanmış durumdaydı; ayrıca fiziksel yükleme adresi ve section offset'leri QEMU derlemesinden farklıydı, bu da adreslerin runtime'da kurtarılmasını zorunlu kılıyordu.

Neden önemli

Bu, bir müşterinin satıcının düzeltmeyi reddettiği bir hataya geçici çözüm bulmak için kendi donanımını exploit etmek zorunda kaldığı, nadir görülen ve eksiksiz belgelenmiş bir vakadır. Bu durum birkaç rahatsız edici gerçeği gözler önüne seriyor: standardizasyon öncesi cihazlar, halefi piyasaya çıkar çıkmaz terk edilebiliyor; donanım offload motorları, TCP'nin bütünlük kontrollerini atlatan biçimde veriyi sessizce bozabiliyor ve son savunma hattı olarak TLS kalıyor; sysfs ayarları tam da bu tür önlemler için var ama satıcılar EOL ürünlere kilitli kabuklar yüklediğinde erişilemez hale geliyor. Ayrıca, bozulmanın izini sürmekten exploit zincirini kararlı hale getirmeye kadar bu emeğin ne kadarının bugün bir LLM ile hata ayıklama ortağı olarak çözülebilir olduğunu da gösteriyor.