Lucene search

K
vulnrichmentLinuxVULNRICHMENT:CVE-2021-47515
HistoryMay 24, 2024 - 3:09 p.m.

CVE-2021-47515 seg6: fix the iif in the IPv6 socket control block

2024-05-2415:09:29
Linux
github.com
3
linux kernel
ipv4 packet
ipv6 socket control block
srh encapsulation
memory area
null pointer dereference

AI Score

6.6

Confidence

High

SSVC

Exploitation

none

Automatable

no

Technical Impact

partial

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.

AI Score

6.6

Confidence

High

SSVC

Exploitation

none

Automatable

no

Technical Impact

partial