CVE-2021-47515

What it actually does

The seg6_do_srh_encap function performs a memset on the IPv6 socket control block (IP6CB) during IPv4-to-IPv6+SRH encapsulation, zeroing the iif field that was previously set by ip_rcv_core; because IPv4 and IPv6 control blocks share the same skb->cb memory, this clears the receiving interface index and triggers a NULL pointer dereference in netdev_rx_stats when commit 0857d6f8c759 is present.

Why it matters to the business

Systems performing SRv6 ip4ip6 encapsulation can experience kernel crashes leading to denial of service, service disruption, and potential loss of network connectivity on affected Linux kernels; the large number of downstream dependents increases the blast radius across distributions and embedded devices.

How an attack unfolds

An attacker sends an IPv4 packet that the kernel intends to encapsulate inside an outer IPv6 header with an SRH; the encapsulation path clears the shared control-block iif value; when the packet is later forwarded, the stats-collection code dereferences a NULL netdev pointer, crashing the kernel.

How to fix it

Upgrade the Linux kernel to commit 1c163f4c7b3f621efff9b28a47abb36f7378d783 or later; apply the corresponding stable or distribution backport that restores IP6CB(skb)->iif after the memset; test SRv6 encapsulation paths after the update.

How to confirm the fix worked

Confirm the presence of commit 1c163f4c7b3f621efff9b28a47abb36f7378d783 in the running kernel source; exercise SRv6 ip4ip6 encapsulation and verify that iif is preserved and no NULL dereference occurs in forwarding stats; run regression tests covering seg6_iptunnel.c and ip_input.c paths.

Typical attack path

1. Craft an IPv4 packet destined for SRv6 ip4ip6 encapsulation
2. Trigger seg6_do_srh_encap which executes the memset on IP6CB(skb)
3. Force the packet through the forwarding path that calls netdev_rx_stats on the original device
4. Trigger NULL dereference and kernel panic

How to detect it

Inspect kernel logs and dmesg for NULL pointer dereference oops in netdev_rx_stats or seg6_do_srh_encap; correlate with traffic containing IPv4 packets encapsulated via SRH ip4ip6; review netfilter or seg6 tracepoints for unexpected iif=0 values on inbound packets.

What your security team should do

• Prioritize kernel updates on all systems that enable seg6 or SRv6 features
• Monitor kernel crash logs for NULL pointer dereferences in netdev_rx_stats after SRv6 encapsulation
• Apply the fix before the next scheduled maintenance window given the 878 days since publication
• Validate the patch in a staging environment that reproduces ip4ip6 encapsulation traffic