CVE-2026-98954

Linux kernel içerisinde aşağıdaki güvenlik açığı giderilmiştir: net: __virtio_net_hdr_to_skb() fonksiyonunda GSO paketleri her zaman ayrıştırılsın 9e8db591326 numaralı commit ("net: avoid false positives in untrusted gso validation"), bazı çağırıcıların (tun_get_user(), tun_xdp_one(), virtnet_receive_done() ve raw_verify_header() gibi) skb->network_header ve skb->dev değerlerini başlatmadan önce virtio_net_hdr_*_to_skb() fonksiyonunu çağırması nedeniyle, __virtio_net_hdr_to_skb() içinde VIRTIO_NET_HDR_F_NEEDS_CSUM içermeyen GSO paketlerinin akış ayrıştırmasından (flow-dissection) önce bir '&& skb->network_header' kontrolü eklemiştir. __alloc_skb() ve __build_skb_around() fonksiyonları skb->network_header değerini 0 olarak başlattığından (~0U olarak başlatılan mac_header ve transport_header'ın aksine), bu dört çağırıcıda skb->network_header her zaman 0 olmuş ve __virtio_net_hdr_to_skb() içindeki akış ayrıştırma işlemi atlanmıştır. Genel olarak skb->network_header, bir boolean bayrağı değil, skb->head üzerinden bir ofsettir (skb_headroom(skb) değeri 0 olduğunda 0 da geçerli bir ofsettir). 'if (gso_type && skb->network_header)' dalı atlandığında, yedek 'else if (gso_type)' yolu paketi ayrıştırmadan, ip_proto veya n_proto değerlerini doğrulamadan ve skb->transport_header değerini ayarlamadan yalnızca nh_min_len + thlen (TCPv4 için 40 bayt) kadar veri çekmiştir. Paket hatalı bir ağ başlığına sahipse reddedilmez ve ardından gelen skb_probe_transport_header() işlemi de başarısız olur; bu durum skb->transport_header değerinin ~0U (0xffff) olarak kalmasına neden olur. Benzer şekilde, bir IPv4 paketi IP seçenekleri (ihl > 5) taşıyorsa veya bir IPv6 paketi genişletme başlıkları taşıyorsa, yalnızca nh_min_len + thlen kadar veri çekmek TCP başlığının skb->head dışında kalmasına yol açabilir. Her iki durumda da skb_gso_transport_seglen() içindeki tcp_hdrlen(skb) sınırlar dışı okuma (out-of-bounds read) gerçekleştirir: BUG: KASAN: slab-out-of-bounds in skb_gso_transport_seglen Read of size 2 by task poc/133 skb_gso_transport_seglen (net/core/gso.c:155) skb_gso_validate_mac_len (net/core/gso.c:270) tbf_enqueue (net/sched/sch_tbf.c:260) dev_qdisc_enqueue (net/core/dev.c:4227) __dev_queue_xmit (net/core/dev.c:4884) Ek olarak, virtio_net_hdr_match_proto() kontrolünün akış ayrıştırmasından önce yalnızca 'if (!skb->protocol)' bloğu içinde yapılması, skb->protocol çağırıcı tarafından önceden ayarlandığında doğrulamanın atlanmasına ve dış L2 protokolü ETH_P_8021Q veya ETH_P_8021AD olan VLAN etiketli çerçevelerin reddedilmesine neden olmuştur. Bu sorun şu adımlarla düzeltilmiştir: 1. tun_get_user(), tun_xdp_one(), virtnet_receive_done() ve raw_verify_header() fonksiyonlarında virtio_net_hdr_*_to_skb() çağrılmadan önce skb->dev ve skb->network_header (ayrıca IFF_TUN için skb->protocol) başlatılmıştır. tun_get_user() içerisinde, __virtio_net_hdr_to_skb() koşulsuz olarak mac_header'ı sıfırladığı için IFF_TUN durumundaki gereksiz skb_reset_mac_header(skb) kaldırılmıştır. 2. __virtio_net_hdr_to_skb() içerisindeki '&& skb->network_header' kontrolü ve doğrulanmamış 'else if (gso_type)' yedeği kaldırılarak, VIRTIO_NET_HDR_F_NEEDS_CSUM içermeyen tüm GSO paketlerinin akış ayrıştırmaya tabi tutulması, taşıma başlıklarının lineer veriye çekilmesi ve skb->transport_header değerinin ayarlanması sağlanmıştır. 3. virtio_net_hdr_match_proto() kontrolü, skb_flow_dissect_flow_keys_basic() işleminden sonraya taşınarak keys.basic.n_proto değerinin hdr_gso_type ile doğrulanması sağlanmıştır.