CVE-2026–46331 — pedit COW Zafiyeti

Diskte hiçbir iz bırakmadan root shell açan CVE-2026–46331, hem teknik olarak hem de disclosure süreciyle çok şey anlatıyor.

Önce şunu anlayalım: COW Ne Demek?

Linux çekirdeği, bir veriyi düzenlemeden önce onu kopyalar. Bu "copy-on-write" (COW) deseni, paylaşılan bellek sayfalarının yanlışlıkla bozulmasını önlemeye yarar. Doğru çalıştığında mükemmel bir mekanizmadır.

Ancak sorun şu ki: Linux'un trafik kontrol (tc) alt sistemindeki act_pedit modülü bu kopyalama işlemini vaktinden önce yapıyor.

Fonksiyon, tcf_pedit_act(), yazılabilir aralığı kontrol ediyor, ama bazı düzenleme anahtarları ofseti çalışma zamanında belirliyor. Yani kontrol yapılırken gerçek hedef belli değil. İş bittikten sonra yazma işlemi özel kopyalanmış bölgenin dışına taşıyor ve kernel, paylaşılan bir sayfa önbelleği sayfasını doğrudan değiştiriyor.

Eğer o sayfa önbellekte bir dosyaya aitse, örneğin /bin/su gibi setuid root yetkili bir binary artık o dosyanın bellekteki görüntüsü saldırganın kontrolünde.

Peki bu Exploit Nasıl Çalışıyor?

Saldırı için iki koşul gerekiyor: act_pedit modülünün yüklenebilir olması ve sistemde ayrıcalıksız kullanıcı namespace'lerinin açık olması. Bu namespace'ler sayesinde saldırgan, içeride geçerli olan CAP_NET_ADMIN yetkisine kavuşuyor ve bu yetki exploit'i tetiklemek için yeterli oluyor.

Test edilen RHEL ve Debian sistemlerinde her iki koşul da varsayılan olarak karşılanıyordu.

Exploit hiçbir zaman diske yazmıyor. /bin/su'nun bellekteki kopyasını poisoning yapıyor, küçük bir payload enjekte ediyor ve değiştirilmiş bu görüntüyü "root" olarak çalıştırıyor. Siz hâlâ /bin/su dosyasının SHA256 hash'ini kontrol edip "temiz" derken root shelli çoktan açılmış oluyor.

Tanıdık gelen bir örnek vermek gerekirse;

Bu açıkla karşılaşınca aklıma ilk olarak Dirty Pipe (2022) geldi. Ardından Copy Fail, DirtyClone ve Dirty Frag geldi. Hepsinin ortak noktası aynı: kernel'ın performans için kullandığı hızlı bir yol, exclusive ownership'e sahip olmadığı bir page'e yazıyor ve bunun sonucunda bedeli page cache ödüyor.

Giriş noktası her seferinde farklı. Bu kez tc eylemleri. Bir dahaki seferinde başka bir hızlı yol olacak.

Bu örüntü bize bir şeyi açıkça söylüyor. Sayfa önbelleği koruması Linux çekirdeğinde hâlâ sistematik bir sorun. Tek tek yamalar geliyor ama benzer hatalar farklı subsystemlarda yeniden çıkıyor.

Kimler Etkileniyor?

Birinci öncelik: Patchi uygulayın ve yeniden başlatın. Özellikle multi-tenant sunucularda, CI/CD runner'larda, Kubernetes node'larında ve build worker'larında "yerel kullanıcı" her zaman güvenilir kullanıcı demek değildir.

Hemen patch uygulayamıyorsanız iki geçici çözüm var.

act_pedit modülünü engelleyin. tc pedit kurallarına ihtiyaç duymayan sistemlerde şu komutla modülü devre dışı bırakabilirsiniz:

echo 'install act_pedit /bin/true' | sudo tee /etc/modprobe.d/disable-act_pedit.conf

echo 'install act_pedit /bin/true' | sudo tee /etc/modprobe.d/disable-act_pedit.conf

Ayrıcalıksız user namespace'lerini kapatın.

RHEL için;

user.max_user_namespaces=0

user.max_user_namespaces=0

Debian/Ubuntu için;

kernel.unprivileged_userns_clone=0

kernel.unprivileged_userns_clone=0

parametresi işe yarıyor. Ama dikkat, bu ayar rootless container'ları, bazı CI sandbox'larını ve sandbox'lı tarayıcıları kırıyor. Üretim ortamında test etmeden uygulamayın.

Sayfa önbelleğini temizlemek için;

echo 3 > /proc/sys/vm/drop_caches

echo 3 > /proc/sys/vm/drop_caches

komutunu kullansanız bile bu sadece bellekteki poisining kopyayı siliyor. Eğer saldırgan zaten root shell açtıysa, o host ele geçirilmiş olarak kabul edilmeli.

Disclousure süreci hakkında kısa bir not düşmek gerekirse;

Fix, Mayıs 2026 sonunda netdev posta listesine rutin bir "veri bozulması düzeltmesi" olarak düştü. Kimse sormadı, kimse alarm vermedi. CVE numarası ancak 16 Haziran 2026'da fix birleştirildiğinde atandı.

Weaponization PoC ertesi gün çıktı.

Exploit edilebilir bir kernel hatasının haftalarca kamuya açık bir posta listesinde oturması ve sonra bir günde weaponized hale gelmesi, bu alanda sadece patch takvimlerini takip etmenin yeterli olmadığını bir kez daha gösterdi. Kernel değişiklik listelerini okumak artık güvenlik araştırmacıları için opsiyonel değil.

Bu yazıyı faydalı bulduysan ve Linux güvenliği üzerine benzer içerikler okumak istiyorsan takip etmeyi unutma.

Kaynaklar: The Hacker News · NIST NVD · kernel.org commit · Red Hat RHSB-2026–008