CVE-2021-47515 in Linux
Summary
by MITRE • 05/24/2024
In the Linux kernel, the following vulnerability has been resolved:
seg6: fix the iif in the IPv6 socket control block
When an IPv4 packet is received, the ip_rcv_core(...) sets the receiving interface index into the IPv4 socket control block (v5.16-rc4, net/ipv4/ip_input.c line 510):
IPCB(skb)->iif = skb->skb_iif;
If that IPv4 packet is meant to be encapsulated in an outer IPv6+SRH header, the seg6_do_srh_encap(...) performs the required encapsulation. In this case, the seg6_do_srh_encap function clears the IPv6 socket control block (v5.16-rc4 net/ipv6/seg6_iptunnel.c line 163):
memset(IP6CB(skb), 0, sizeof(*IP6CB(skb)));
The memset(...) was introduced in commit ef489749aae5 ("ipv6: sr: clear IP6CB(skb) on SRH ip4ip6 encapsulation") a long time ago (2019-01-29).
Since the IPv6 socket control block and the IPv4 socket control block share the same memory area (skb->cb), the receiving interface index info is lost (IP6CB(skb)->iif is set to zero).
As a side effect, that condition triggers a NULL pointer dereference if commit 0857d6f8c759 ("ipv6: When forwarding count rx stats on the orig netdev") is applied.
To fix that issue, we set the IP6CB(skb)->iif with the index of the receiving interface once again.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/25/2025
This vulnerability exists in the Linux kernel's handling of IPv6 Segment Routing headers and demonstrates a critical flaw in socket control block management during packet processing. The issue manifests when IPv4 packets are received and subsequently encapsulated within IPv6+SRH headers through the segment routing mechanism. The core problem arises from the shared memory allocation between IPv4 and IPv6 socket control blocks within the skb->cb structure, creating a race condition where data from one protocol's control block overwrites data from another during encapsulation operations.
The technical implementation involves multiple kernel subsystems working in concert to process incoming packets. When an IPv4 packet arrives, the ip_rcv_core function properly stores the receiving interface index in the IPv4 socket control block at line 510 of net/ipv4/ip_input.c. However, during subsequent encapsulation operations, the seg6_do_srh_encap function executes a memset operation on the IPv6 socket control block at line 163 of net/ipv6/seg6_iptunnel.c, clearing all control block data. This memset operation was introduced in 2019 and serves to reset the IPv6 control block for SRH encapsulation purposes, but it inadvertently destroys the interface index information that was previously set by the IPv4 processing path.
The operational impact of this vulnerability extends beyond simple data loss to potentially cause system instability through NULL pointer dereferences. When the kernel applies commit 0857d6f8c759, which implements forwarding statistics counting on the original network device, the cleared interface index information causes a NULL pointer dereference during packet forwarding operations. This represents a classic case of memory corruption leading to kernel panic conditions that can compromise system stability and availability. The vulnerability affects systems running Linux kernel versions prior to the fix, particularly those implementing IPv6 segment routing functionality with IPv4-in-IPv6 encapsulation.
The mitigation strategy involves restoring the receiving interface index information after the memset operation in the seg6_do_srh_encap function. This approach ensures that the interface index information is preserved during the encapsulation process while maintaining the intended clearing of other control block fields for SRH operations. From a cybersecurity perspective, this vulnerability aligns with CWE-121, heap-based buffer overflow, and CWE-125, out-of-bounds read, as the memory corruption occurs due to improper handling of shared memory structures. The ATT&CK framework categorizes this under T1059.001, command and script interpreter, as exploitation could involve crafting specific network traffic patterns to trigger the vulnerable code path, and T1489, service stoppage, due to potential system crashes and denial of service conditions. The fix demonstrates proper defensive programming practices by ensuring that critical interface information is preserved during protocol conversion operations while maintaining the integrity of other control block fields that require clearing for security and correctness reasons.