CVE-2026-81003

Linux kernel'de aşağıdaki güvenlik açığı giderilmiştir: net/iucv: afiucv_hs_rcv() fonksiyonundaki çerçevelerin giriş cihazına göre filtrelenmesi afiucv_hs_rcv(), taşıma başlığındaki yalnızca dört adet 8 baytlık isim alanını eşleştirerek iucv_sk_list üzerinden bir soket seçer. Çerçevenin geldiği net_device üzerinde herhangi bir kontrol yapılmamaktadır. Bu durum, herhangi bir netdev üzerinden gelen bir çerçevenin bir AF_IUCV soketine iletilmesine neden olabilir. Bunun sonucunda üç sorun ortaya çıkar. Birincisi, HiperSockets üzerinden gelen bir çerçeve, iucv->hs_dev == NULL olan klasik z/VM IUCV taşımasına bağlı bir sokete iletilebilir. iucv_sock_bind(), talep edilen kullanıcı kimliği iucv_userid ile eşleştiğinde, aynı tanımlayıcıyı taşıyan bir HiperSockets cihazına sahip bir konukta bile her zaman klasik yolu izler. Böyle bir eşleşme için afiucv_hs_callback_syn() tarafından oluşturulan alt soket, hs_dev = NULL ve transport = AF_IUCV_TRANS_HIPER değerlerini devralır, bu nedenle üzerindeki ilk send() çağrısı -ENODEV döndürür. accept() fonksiyonuna iletilen soket kullanılamaz durumdadır. İkincisi, bir netdev üzerinden gelen bir çerçeve, farklı bir IQD cihazına bağlı bir sokete iletilebilir. Bu durum şunlara yol açabilir: - Kabul kuyruğunun tükenmesi (DoS) - Alt sokette saldırgan tarafından kontrol edilen eş kimliği - Mevcut soketlere veri enjeksiyonu - Sahte yanıtların gönderildiği IQD fabric üzerinde fabric gürültüsü - Kurulmuş bağlantıların sonlandırılması Üçüncüsü, iucv_sock_alloc() fonksiyonu sk_alloc(&init_net, ...) çağırdığından tüm AF_IUCV soketleri init_net içinde yer alır. Ancak bir namespace içindeki netdev cihazlarından gelen çerçeveler bile bir IUCV soketine iletilebilir. Dolayısıyla, yalnızca o namespace içinde geçerli olan CAP_NET_RAW yeteneğine sahip, ayrıcalıksız bir kullanıcı ve ağ namespace'indeki bir işlem, kendi lo cihazı üzerinden ham bir ETH_P_AF_IUCV çerçevesi gönderebilir ve bunun init_net soketleriyle eşleşmesini sağlayabilir. hs_dev değeri giriş cihazıyla eşleşmeyen tüm soketler atlanarak bu üç sorun da giderilmiştir. Klasik bir z/VM IUCV soketi hs_dev == NULL değerine sahiptir; giriş cihazı asla NULL değildir, bu nedenle klasik soketler otomatik olarak atlanır. Bağlanmamış bir HIPER soketi de hs_dev == NULL değerine sahiptir ve atlanır. Bağlı bir HIPER soketine yalnızca bağlandığı tam IQD cihazından erişilebilir. hs_dev her zaman init_net içindeki bir cihaz olduğundan (iucv_sock_bind() özel olarak for_each_netdev_rcu(&init_net, ...) taraması yapar), giriş cihazı başka bir namespace'e ait olan bir çerçeve hiçbir soketle eşleşmez. HiperSockets üzerinden AF_IUCV'nin bağlantı başına kimlik doğrulama sağlamadığına dikkat edilmelidir: sıra numaraları, TLS veya nonce bulunmamaktadır. Bir bağlantıyı tanımlayan dört isim alanı, paylaşılan HiperSockets segmentinde (VCHID) açık metin olarak değiştirilir. Aynı HiperSockets segmentindeki herhangi bir ana bilgisayar, mevcut bir bağlantıya karşı herhangi bir çerçeve türünü taklit edebilir. Bu, söz konusu yama ile değiştirilmeyen protokol düzeyinde bir özelliktir. Düzeltme, saldırı yüzeyini yalnızca aynı HiperSockets segmentinde bulunan eşlerle sınırlandırır.