netdev - Re: [PATCH net] ip6_tunnel: use skb_vlan_inet_prepare() in __ip6_tnl

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-Id: <37F1606C-F47C-4E56-8EA2-BC0D1CCAB835@hammer065.de>
Date: Sat, 31 Jan 2026 02:28:40 +0100
From: hammer065 <hammer065@...mer065.de>
To: Eric Dumazet <edumazet@...gle.com>
Cc: Hirokazu MORIKAWA <morikw2@...il.com>,
 davem@...emloft.net,
 eric.dumazet@...il.com,
 horms@...nel.org,
 kuba@...nel.org,
 netdev@...r.kernel.org,
 pabeni@...hat.com,
 syzbot+d4dda070f833dc5dc89a@...kaller.appspotmail.com
Subject: Re: [PATCH net] ip6_tunnel: use skb_vlan_inet_prepare() in
 __ip6_tnl_rcv()

Hello together,

I’ll chime in as I was the original reporter of the downstream issue at OpenWRT:
https://github.com/openwrt/openwrt/issues/21737

> Can you provide detailed instructions ?
When setting up an ipip6 (IPv4 in IPv6) tunnel on top of another (IPv6-only) interface,
received ipip6 packets do not get decapsulated to the tunnel interface.
However, one can see that they get received on the parent (IPv6-only) interface.


Steps to reproduce:
1. Have an IPv6-only interface, which has access to another server which receives and answers ipip6 packets (for example an AFTR server of your ISP).
2. Create an ipip6 tunnel interface, using the afore mentioned interface as a „parent“ and use it as a NAT.
3. Send *any* IPv4 packet (in this example an ICMP ping) which then gets encapsulated as an ipip6 packet.

Local IPv6 device <-IPv6-> AFTR-Server / Remote IPv6 <-IPv4-> Remote IPv4

ip a:
xx: ipv6-only: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether
    inet6 [Local IPv6]/128 scope global dynamic noprefixroute
       valid_lft forever preferred_lft forever
yy: ipip6-tunnel@...6-only: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1460 qdisc noqueue state UNKNOWN group default qlen 1000
    link/tunnel6 [Local IPv6] peer [Remote IPv6] permaddr abcd:ef01:2345::
    inet 192.0.0.2 peer 192.0.0.1/32 brd 255.255.255.255 scope global ipip6-tunnel
       valid_lft forever preferred_lft forever

ip -6 t:
ipip6-tunnel: ip/ipv6 remote [Remote IPv6] local [Local IPv6] dev ipv6-only encaplimit none hoplimit 64 tclass 0x00 flowlabel 0x00000 (flowinfo 0x00000000)


Expected:
When the AFTR server sends the ipip6 encapsulated response packet, it gets decapsulated on the tunnel interface as an IPv4 packet.

tcpdump -i ipv6-only:
IP6 [Local IPv6] > [Remote IPv6]: IP 192.0.0.2 > [Remote IPv4]: ICMP echo request, id 56869, seq 0, length 64
IP6 [Remote IPv6] > [Local IPv6]: IP [Remote IPv4] > 192.0.0.2: ICMP echo reply, id 56869, seq 0, length 64
IP6 [Local IPv6] > [Remote IPv6]: IP 192.0.0.2 > [Remote IPv4]: ICMP echo request, id 56869, seq 1, length 64
IP6 [Remote IPv6] > [Local IPv6]: IP [Remote IPv4] > 192.0.0.2 ICMP echo reply, id 56869, seq 1, length 64

tcpdump -i ipip6-tunnel:
IP 192.0.0.2 > [Remote IPv4]: ICMP echo request, id 56869, seq 0, length 64
IP [Remote IPv4] > 192.0.0.2: ICMP echo reply, id 56869, seq 0, length 64
IP 192.0.0.2 > [Remote IPv4]: ICMP echo request, id 56869, seq 1, length 64
IP [Remote IPv4] > 192.0.0.2: ICMP echo reply, id 56869, seq 1, length 64


Actual (due to the mentioned commit):
The ipip6 packet does not get decapsulated, so only the sent IPv4 packets are present on the tunnel interface.
However, the ipip6 packets get properly received on the parent interface.

tcpdump -i ipv6-only:
IP6 [Local IPv6] > [Remote IPv6]: IP 192.0.0.2 > [Remote IPv4]: ICMP echo request, id 56869, seq 0, length 64
IP6 [Remote IPv6] > [Local IPv6]: IP [Remote IPv4] > 192.0.0.2: ICMP echo reply, id 56869, seq 0, length 64
IP6 [Local IPv6] > [Remote IPv6]: IP 192.0.0.2 > [Remote IPv4]: ICMP echo request, id 56869, seq 1, length 64
IP6 [Remote IPv6] > [Local IPv6]: IP [Remote IPv4] > 192.0.0.2 ICMP echo reply, id 56869, seq 1, length 64

tcpdump -i ipip6-tunnel:
IP 192.0.0.2 > [Remote IPv4]: ICMP echo request, id 56869, seq 0, length 64
IP 192.0.0.2 > [Remote IPv4]: ICMP echo request, id 56869, seq 1, length 64


> I have no idea what MAP-E or DS-Lite are.
I have no idea what MAP-E is, but Dual-Stack-Lite is a way for ISPs to save on IPv4 addresses
by providing a CG-NAT in form of an dedicated AFTR server, which receive and respond to ipip6 packets
and therefore providing access to the IPv4 internet with customers only receiving an IPv6 address(-range).

I hope this clears everything up. If not, feel free to ask further questions about the issue. :)
If it helps, I can provide a bare-bones example config for OpenWRT to test against.

Best regards,

-- hammer065