CVE-2022-48936

What it actually does

The flaw prevents proper updating of the outer IP header during GSO segmentation for SKB_GSO_IPXIP4 packets when net_failover and IPIP encapsulation are combined with SKB_GSO_DODGY, causing inet_gso_segment to skip the outer header and resulting in unmodified packets being dropped downstream.

Why it matters to the business

Cloud and virtualized environments using IPVS load balancing with IPIP tunnels and virtio_net failover experience TCP connection drops and service interruptions, increasing operational overhead and potential downtime for dependent workloads.

How an attack unfolds

An attacker triggers GRO-processed packets forwarded into a VM using net_failover and IPIP encapsulation; the kernel's gso_segment path skips the outer header due to the rare SKB_GSO_DODGY plus tunnel flag combination, leaving the outer IP unchanged so remote hosts drop the traffic.

How to fix it

Apply the upstream kernel fix that resets network_header when gso_segment returns NULL; for Android, upgrade platform/frameworks/base and platform/packages/modules/Connectivity to the 2022-06-01 releases in the 11 and 12L branches.

How to confirm the fix worked

Confirm kernel or Android build contains the gso_segment network_header reset logic; reproduce the GRO-to-IPIP path in a net_failover test VM and verify outer header is correctly rewritten with no subsequent drops.

Typical attack path

1. Send TCP traffic that undergoes GRO on the host before delivery to a virtio_net VM
2. VM performs IPVS full NAT followed by IPIP encapsulation on the packet
3. net_failover transmit path invokes skb_mac_gso_segment with GSO_IPXIP4 and DODGY flags
4. inet_gso_segment skips outer header and returns without modification
5. virtio_net transmits malformed packet that is dropped at the remote endpoint

How to detect it

Review kernel logs and network traces for tcp4_gso_segment returning NULL followed by inet_gso_segment skipping the outer header; correlate with virtnet_poll and ipip_tunnel_xmit activity on systems using net_failover.

What your security team should do

• Patch affected kernels and Android builds immediately given the 786-day exposure window
• Audit virtualization and tunneling configurations for net_failover plus IPIP usage
• Monitor for increased packet drops on virtio_net and ipip interfaces until remediation is complete