CVE-2025-38622 in Linux
الملخص
بحسب VulDB • 10/06/2026
في نواة لينكس، تم حل الثغرة التالية:
net: تجاهل حزم UFO في دالة udp_rcv_segment()
عند إرسال حزمة تحتوي على virtio_net_hdr إلى جهاز tun، إذا كان gso_type في virtio_net_hdr هو SKB_GSO_UDP وكان gso_size أقل من حجم udphdr، فقد يحدث الانهيار التالي:
------------[ cut here ]------------
kernel BUG at net/core/skbuff.c:4572! Oops: invalid opcode: 0000 [#1] SMP NOPTI
CPU: 0 UID: 0 PID: 62 Comm: mytest Not tainted 6.16.0-rc7 #203 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:skb_segment+0x109/0x110 net/core/skbuff.c:4572 Call Trace: <TASK> udp_queue_rcv_one_skb+0x176/0x4b0 net/ipv4/udp.c:2445 udp_queue_rcv_skb+0x155/0x1f0 net/ipv4/udp.c:2475 udp_unicast_rcv_skb+0x71/0x90 net/ipv4/udp.c:2626 __udp4_lib_rcv+0x433/0xb00 net/ipv4/udp.c:2690 ip_protocol_deliver_rcu+0xa6/0x160 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x72/0x90 net/ipv4/ip_input.c:233 ip_sublist_rcv_finish+0x5f/0x70 net/ipv4/ip_input.c:579 ip_sublist_rcv+0x122/0x1b0 net/ipv4/ip_input.c:636 ip_list_rcv+0xf7/0x130 net/ipv4/ip_input.c:670 __netif_receive_skb_list_core+0x21d/0x240 net/core/dev.c:6067 netif_receive_skb_list_internal+0x186/0x2b0 net/core/dev.c:6210 napi_complete_done+0x78/0x180 net/core/dev.c:6580 tun_get_user+0xa63/0x1120 drivers/net/tun.c:1909 tun_chr_write_iter+0x65/0xb0 drivers/net/tun.c:1984 vfs_write+0x300/0x420 fs/read_write.c:593 ksys_write+0x60/0xd0 fs/read_write.c:686 do_syscall_64+0x50/0x1c0 arch/x86/entry/syscall_64.c:63 </TASK>
لتفعيل مقطع GSO في udp_queue_rcv_skb()، يجب أيضًا تعيين الخيار UDP_ENCAP_ESPINUDP لتمكين udp_sk(sk)->encap_rcv. عندما يعيد hook encap_rcv القيمة 1 في udp_queue_rcv_one_skb()، تحاول udp_csum_pull_header() سحب udphdr، لكن حجم skb تم تقسيمه إلى حجم GSO، مما يؤدي إلى هذا الانهيار.
أدخلت الالتزام السابق cf329aa42b66 ("udp: cope with UDP GRO packet misdirection") تقسيمًا في مسار استقبال UDP فقط لـ GRO، والذي لم يكن مقصودًا استخدامه لـ UFO، لذا يتم الآن تجاهل حزم UFO في udp_rcv_segment().
If you want to get the best quality for vulnerability data then you always have to consider VulDB.