CVE-2025-68363

What it actually does

The bpf_skb_check_mtu helper dereferences skb->transport_header without first verifying it was initialized via skb_transport_header_was_set when the BPF_MTU_CHK_SEGS flag is supplied, allowing use of an unset header offset under specific GSO and test-run conditions.

Why it matters to the business

Systems running BPF programs that perform MTU segment checks may trigger kernel warnings or unexpected behavior during network processing or testing, increasing operational noise and potential for instability on unpatched kernels; high downstream kernel prevalence amplifies exposure across container and orchestration environments.

How an attack unfolds

An attacker loads or triggers a BPF program that invokes bpf_skb_check_mtu with the BPF_MTU_CHK_SEGS flag on an skb lacking a transport header (possible via crafted packets or test-run paths), causing the helper to access an invalid offset and hit the debug warning path.

How to fix it

Upgrade the Linux kernel to a version containing commit b3171a5e4622e915e94599a55f4964078bdec27e or later; rebuild and redeploy any downstream packages such as argocd-image-updater that embed the affected kernel code.

How to confirm the fix worked

Confirm skb_transport_header_was_set is called before transport_header use in bpf_skb_check_mtu; run bpf_prog_test_run with DEBUG_NET enabled and GSO skbs to verify absence of the WARN_ON_ONCE; check kernel build contains the referenced commit.

Typical attack path

1. Craft or obtain a BPF program using bpf_skb_check_mtu with BPF_MTU_CHK_SEGS
2. Arrange for an ingress skb or test skb that has gso_size set but transport_header unset
3. Load and attach the program or execute via bpf_prog_test_run_skb
4. Trigger packet processing that reaches the unchecked header access

How to detect it

Search kernel logs for the specific WARN_ON_ONCE in skb_gso_validate_network_len called from bpf_skb_check_mtu during bpf_test_run; inspect BPF program load and attach events around the time of the warning.

What your security team should do

• Prioritize kernel upgrades on all systems exposing BPF to untrusted programs or using network MTU helpers
• Monitor EPSS trend and re-evaluate if exploit maturity increases
• Audit custom BPF programs for use of BPF_MTU_CHK_SEGS and add defensive header checks where possible
• Test patched kernels under bpf_prog_test_run and production traffic before broad rollout