iOS 26 Kernel Attack Surface Neden Bu Kadar Dikkat Çekiyor?

Son günlerde iOS 26 / A17 üzerinde XNU kernel araştırıyorum. Apple Product Security'ye gönderdiğim bir kernel panic raporunda, Apple tarafı gönderdiğim panic logunun gerçek olduğunu doğruladı.

“The attached panic log is genuine.”

Genişletmek için tıkla ...

Araştırmadaki cihaz:

• iPhone 15 Pro / A17
• iOS 26.0
• XNU 12377.0.154.0.2~118
• Kernel Data Abort
• FAR = 0x58
• cihazın tamamen reboot olması

Şu an bunun UAF, LPE veya kernel R/W olduğunu iddia etmiyorum. Apple'ın istediği şey de önce panic'i tetikleyen işlemi tamamen izole etmek ve bunun normal sandboxed app'ten erişilebilir olup olmadığını göstermek.

Fakat daha büyük resim ilginç​

Apple'ın kendi iOS 26.6 security notes'larına bakıldığında Kernel kategorisinde çok sayıda memory-safety problemi bulunuyor. Bunlar arasında UAF, out-of-bounds read, race condition, memory initialization ve kernel memory corruption gibi problemler var. Bazılarında doğrudan “An app may be able to...” şeklinde sandboxed uygulama kaynaklı etkiler belirtiliyor.

Örneğin Apple'ın aynı güvenlik dokümanında:

• kernel memory corruption
• kernel memory disclosure
• unexpected system termination
• kernel memory write
• use-after-free
• out-of-bounds read

gibi farklı Kernel etkileri için ayrı CVE'ler bulunuyor.

Bu yüzden benim açımdan iOS 26'da özellikle XNU kernel'in userspace'ten ulaşılabilen attack surface'i oldukça ilginç bir araştırma alanı haline geliyor.

Benim bulduğum panic'in bunlardan biri olduğunu şu anda söylemiyorum. Tam tersine, root cause ortaya çıkmadan böyle bir sınıflandırma yapmak istemiyorum.

Ama A17 / iOS 26 üzerinde:

sandboxed userspace → kernel interface → XNU → memory-safety fault

zincirinin araştırılması bence ciddi şekilde değerli.

Apple tarafındaki mevcut raporu da bu nedenle özellikle minimal trigger ve sandbox reachability üzerine yoğunlaştırıyorum.

Araştırma devam ediyor.