CVE-2025-68363 in Linux
Summary
by MITRE • 12/24/2025
In the Linux kernel, the following vulnerability has been resolved:
bpf: Check skb->transport_header is set in bpf_skb_check_mtu
The bpf_skb_check_mtu helper needs to use skb->transport_header when the BPF_MTU_CHK_SEGS flag is used:
bpf_skb_check_mtu(skb, ifindex, &mtu_len, 0, BPF_MTU_CHK_SEGS)
The transport_header is not always set. There is a WARN_ON_ONCE report when CONFIG_DEBUG_NET is enabled + skb->gso_size is set + bpf_prog_test_run is used:
WARNING: CPU: 1 PID: 2216 at ./include/linux/skbuff.h:3071 skb_gso_validate_network_len bpf_skb_check_mtu bpf_prog_3920e25740a41171_tc_chk_segs_flag # A test in the next patch bpf_test_run bpf_prog_test_run_skb
For a normal ingress skb (not test_run), skb_reset_transport_header is performed but there is plan to avoid setting it as described in commit 2170a1f09148 ("net: no longer reset transport_header in __netif_receive_skb_core()").
This patch fixes the bpf helper by checking skb_transport_header_was_set(). The check is done just before skb->transport_header is used, to avoid breaking the existing bpf prog. The WARN_ON_ONCE is limited to bpf_prog_test_run, so targeting bpf-next.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 01/12/2026
The vulnerability described in CVE-2025-68363 resides within the Linux kernel's eBPF (extended Berkeley Packet Filter) subsystem, specifically affecting the bpf_skb_check_mtu helper function. This issue manifests when the BPF_MTU_CHK_SEGS flag is utilized during packet processing, creating a potential instability condition that could lead to system warnings and operational disruptions. The core problem emerges from the improper handling of the skb->transport_header field, which is not consistently initialized across all packet processing paths, particularly in test scenarios involving bpf_prog_test_run functionality.
The technical flaw occurs when the bpf_skb_check_mtu helper function attempts to access skb->transport_header without first verifying its validity, leading to a WARN_ON_ONCE message when CONFIG_DEBUG_NET is enabled. This warning appears specifically during bpf_prog_test_run execution when skb->gso_size is set, indicating that the transport header has not been properly established. The vulnerability stems from the fact that while normal ingress packets undergo skb_reset_transport_header processing, newer kernel development directions aim to eliminate this reset operation as outlined in commit 2170a1f09148, creating inconsistency in header management across different packet processing contexts.
The operational impact of this vulnerability extends beyond simple warning messages to potentially destabilizing the kernel's network processing pipeline. When the bpf_skb_check_mtu helper encounters an uninitialized transport_header, it can trigger kernel warnings that may indicate deeper underlying issues in packet segmentation handling. This situation is particularly concerning in high-throughput network environments where eBPF programs are extensively used for packet inspection, filtering, and modification. The vulnerability affects systems running kernel versions where the bpf helper is invoked with BPF_MTU_CHK_SEGS flag, especially when combined with debugging configurations that enable CONFIG_DEBUG_NET.
The mitigation strategy involves implementing a proper validation check using skb_transport_header_was_set() before accessing skb->transport_header in the bpf_skb_check_mtu helper function. This approach ensures that the existing eBPF programs continue to function correctly while preventing the kernel from triggering warnings during test execution scenarios. The fix maintains backward compatibility by checking the header status just before usage rather than modifying the broader packet processing flow, thereby preserving existing program behavior while addressing the specific edge case that causes the warning condition. This solution aligns with the ATT&CK framework's defense evasion techniques by preventing kernel-level instability that could be exploited to disrupt network operations or potentially mask other underlying security issues. The vulnerability classification aligns with CWE-681, which addresses incorrect use of a resource in a manner that could lead to unintended behavior, and the fix demonstrates proper defensive programming practices through conditional validation before resource access.