Re: [PATCH net] ip6_tunnel: use skb_vlan_inet_prepare() in __ip6_tnl_rcv()

Re: [PATCH net] ip6_tunnel: use skb_vlan_inet_prepare() in __ip6_tnl_rcv()

[Hirokazu MORIKAWA]

[REGRESSION] ip6_tunnel: IPv4 traffic broken in MAP-E/DS-Lite since
commit df5ffde96693

Hi,
I am reporting a regression in the IPv6 tunneling stack (MAP-E and
DS-Lite) introduced in kernel 6.12.67.

[Description] After upgrading the kernel from 6.12.66 to 6.12.67 in
the OpenWrt snapshot, IPv4 packets can no longer be sent to the
external network via MAP-E or DS-Lite interfaces.
[Environment]
* Hardware: FriendlyElec NanoPi R6C
* OS: OpenWrt snapshot
* Kernel version: 6.12.67 (Broken), 6.12.66 (Working)
* Protocol: MAP-E and DS-Lite
[Culprit] By bisecting/reverting individual commits, I have identified
that the following commit is responsible for this issue:
"ip6_tunnel: use skb_vlan_inet_prepare() in __ip6_tnl_rcv()" (Link to
the patch: https://lore.kernel.org/netdev/20260107163109.4188620-1-edumazet@google.com/)
Reverting this specific commit on top of kernel 6.12.67 restores
normal connectivity for both MAP-E and DS-Lite.
[Steps to reproduce]
1. Set up a MAP-E or DS-Lite connection on kernel 6.12.67.
2. Attempt to send IPv4 traffic (e.g., ping 8.8.8.8).
3. The packets fail to reach the destination.

Best regards, nxhack

Re: [PATCH net] ip6_tunnel: use skb_vlan_inet_prepare() in __ip6_tnl_rcv()

[Eric Dumazet]

On Fri, Jan 30, 2026 at 5:15 AM Hirokazu MORIKAWA <morikw2@gmail.com> wrote:
>
> [REGRESSION] ip6_tunnel: IPv4 traffic broken in MAP-E/DS-Lite since
> commit df5ffde96693
>
> Hi,
> I am reporting a regression in the IPv6 tunneling stack (MAP-E and
> DS-Lite) introduced in kernel 6.12.67.
>
> [Description] After upgrading the kernel from 6.12.66 to 6.12.67 in
> the OpenWrt snapshot, IPv4 packets can no longer be sent to the
> external network via MAP-E or DS-Lite interfaces.
> [Environment]
> * Hardware: FriendlyElec NanoPi R6C
> * OS: OpenWrt snapshot
> * Kernel version: 6.12.67 (Broken), 6.12.66 (Working)
> * Protocol: MAP-E and DS-Lite
> [Culprit] By bisecting/reverting individual commits, I have identified
> that the following commit is responsible for this issue:
> "ip6_tunnel: use skb_vlan_inet_prepare() in __ip6_tnl_rcv()" (Link to
> the patch: https://lore.kernel.org/netdev/20260107163109.4188620-1-edumazet@google.com/)
> Reverting this specific commit on top of kernel 6.12.67 restores
> normal connectivity for both MAP-E and DS-Lite.
> [Steps to reproduce]
> 1. Set up a MAP-E or DS-Lite connection on kernel 6.12.67.
> 2. Attempt to send IPv4 traffic (e.g., ping 8.8.8.8).
> 3. The packets fail to reach the destination.

Thanks for the report.

Can you provide detailed instructions ?

Apparently none of our selftests caught the issue, it would be great to add one.

I have no idea what MAP-E or DS-Lite are.

Re: [PATCH net] ip6_tunnel: use skb_vlan_inet_prepare() in __ip6_tnl_rcv()

[Gary Guo]

On Fri Jan 30, 2026 at 12:00 PM GMT, Eric Dumazet wrote:
> On Fri, Jan 30, 2026 at 5:15 AM Hirokazu MORIKAWA <morikw2@gmail.com> wrote:
>>
>> [REGRESSION] ip6_tunnel: IPv4 traffic broken in MAP-E/DS-Lite since
>> commit df5ffde96693
>>
>> Hi,
>> I am reporting a regression in the IPv6 tunneling stack (MAP-E and
>> DS-Lite) introduced in kernel 6.12.67.
>>
>> [Description] After upgrading the kernel from 6.12.66 to 6.12.67 in
>> the OpenWrt snapshot, IPv4 packets can no longer be sent to the
>> external network via MAP-E or DS-Lite interfaces.
>> [Environment]
>> * Hardware: FriendlyElec NanoPi R6C
>> * OS: OpenWrt snapshot
>> * Kernel version: 6.12.67 (Broken), 6.12.66 (Working)
>> * Protocol: MAP-E and DS-Lite
>> [Culprit] By bisecting/reverting individual commits, I have identified
>> that the following commit is responsible for this issue:
>> "ip6_tunnel: use skb_vlan_inet_prepare() in __ip6_tnl_rcv()" (Link to
>> the patch: https://lore.kernel.org/netdev/20260107163109.4188620-1-edumazet@google.com/)
>> Reverting this specific commit on top of kernel 6.12.67 restores
>> normal connectivity for both MAP-E and DS-Lite.
>> [Steps to reproduce]
>> 1. Set up a MAP-E or DS-Lite connection on kernel 6.12.67.
>> 2. Attempt to send IPv4 traffic (e.g., ping 8.8.8.8).
>> 3. The packets fail to reach the destination.
>
> Thanks for the report.
>
> Can you provide detailed instructions ?
>
> Apparently none of our selftests caught the issue, it would be great to add one.
>
> I have no idea what MAP-E or DS-Lite are.

Hi Eric,

I'm troubleshooting a regression on my system after 6.12.63 -> 6.12.67 upgrade
and my bisecting point to this patch too.

My setup is a IP6GRE tunnel over WireGuard, and after the upgrade it can no
longer receive any packets over the GRE tunnel. Using tcpdump I can see packets
coming in from WireGuard, but they don't end up in the GRE interface. Reverting
this change, everything works again.

I am not a kernel netdev expert, but to me it looks like skb_vlan_inet_prepare
ignores the network_header on the packet completely, which is going to be non
zero if skb->data != skb->head, given before calling the function,
skb_reset_network_header is invoked. And in my case where there is an outer
encapsulation layer, skb->data != skb->head would actually happen.

Best,
Gary

Re: [PATCH net] ip6_tunnel: use skb_vlan_inet_prepare() in __ip6_tnl_rcv()

[Ricardo B. Marlière]

On Fri Jan 30, 2026 at 9:00 AM -03, Eric Dumazet wrote:
> On Fri, Jan 30, 2026 at 5:15 AM Hirokazu MORIKAWA <morikw2@gmail.com> wrote:
>>
>> [REGRESSION] ip6_tunnel: IPv4 traffic broken in MAP-E/DS-Lite since
>> commit df5ffde96693
>>
>> Hi,
>> I am reporting a regression in the IPv6 tunneling stack (MAP-E and
>> DS-Lite) introduced in kernel 6.12.67.
>>
>> [Description] After upgrading the kernel from 6.12.66 to 6.12.67 in
>> the OpenWrt snapshot, IPv4 packets can no longer be sent to the
>> external network via MAP-E or DS-Lite interfaces.
>> [Environment]
>> * Hardware: FriendlyElec NanoPi R6C
>> * OS: OpenWrt snapshot
>> * Kernel version: 6.12.67 (Broken), 6.12.66 (Working)
>> * Protocol: MAP-E and DS-Lite
>> [Culprit] By bisecting/reverting individual commits, I have identified
>> that the following commit is responsible for this issue:
>> "ip6_tunnel: use skb_vlan_inet_prepare() in __ip6_tnl_rcv()" (Link to
>> the patch: https://lore.kernel.org/netdev/20260107163109.4188620-1-edumazet@google.com/)
>> Reverting this specific commit on top of kernel 6.12.67 restores
>> normal connectivity for both MAP-E and DS-Lite.
>> [Steps to reproduce]
>> 1. Set up a MAP-E or DS-Lite connection on kernel 6.12.67.
>> 2. Attempt to send IPv4 traffic (e.g., ping 8.8.8.8).
>> 3. The packets fail to reach the destination.
>
> Thanks for the report.
>
> Can you provide detailed instructions ?
>
> Apparently none of our selftests caught the issue, it would be great to add one.

Perhaps l2_tos_ttl_inherit.sh [1]? I've seen a timeout in this test that
went away after testing commit 9990ddf47d41 ("net: tunnel: make
skb_vlan_inet_prepare() return drop reasons") like mentioned here:

https://lore.kernel.org/netdev/DGAR3PO1D33S.1TI7W7U4SPTOG@suse.com/

It seems that that commit 81c734dae203 ("ip6_tunnel: use
skb_vlan_inet_prepare() in __ip6_tnl_rcv()") uses the new
skb_vlan_inet_prepare added in v6.13, which broke 6.12.

[1]: `# │    gre │     6 │     4 │ inherit 0x4c │   inherit 90 │ false │ `..<hangs>

>
> I have no idea what MAP-E or DS-Lite are.

Re: [PATCH net] ip6_tunnel: use skb_vlan_inet_prepare() in __ip6_tnl_rcv()

[Eric Dumazet]

On Tue, Feb 10, 2026 at 1:42 PM Ricardo B. Marlière <rbm@suse.com> wrote:
>
> On Fri Jan 30, 2026 at 9:00 AM -03, Eric Dumazet wrote:
> > On Fri, Jan 30, 2026 at 5:15 AM Hirokazu MORIKAWA <morikw2@gmail.com> wrote:
> >>
> >> [REGRESSION] ip6_tunnel: IPv4 traffic broken in MAP-E/DS-Lite since
> >> commit df5ffde96693
> >>
> >> Hi,
> >> I am reporting a regression in the IPv6 tunneling stack (MAP-E and
> >> DS-Lite) introduced in kernel 6.12.67.
> >>
> >> [Description] After upgrading the kernel from 6.12.66 to 6.12.67 in
> >> the OpenWrt snapshot, IPv4 packets can no longer be sent to the
> >> external network via MAP-E or DS-Lite interfaces.
> >> [Environment]
> >> * Hardware: FriendlyElec NanoPi R6C
> >> * OS: OpenWrt snapshot
> >> * Kernel version: 6.12.67 (Broken), 6.12.66 (Working)
> >> * Protocol: MAP-E and DS-Lite
> >> [Culprit] By bisecting/reverting individual commits, I have identified
> >> that the following commit is responsible for this issue:
> >> "ip6_tunnel: use skb_vlan_inet_prepare() in __ip6_tnl_rcv()" (Link to
> >> the patch: https://lore.kernel.org/netdev/20260107163109.4188620-1-edumazet@google.com/)
> >> Reverting this specific commit on top of kernel 6.12.67 restores
> >> normal connectivity for both MAP-E and DS-Lite.
> >> [Steps to reproduce]
> >> 1. Set up a MAP-E or DS-Lite connection on kernel 6.12.67.
> >> 2. Attempt to send IPv4 traffic (e.g., ping 8.8.8.8).
> >> 3. The packets fail to reach the destination.
> >
> > Thanks for the report.
> >
> > Can you provide detailed instructions ?
> >
> > Apparently none of our selftests caught the issue, it would be great to add one.
>
> Perhaps l2_tos_ttl_inherit.sh [1]? I've seen a timeout in this test that
> went away after testing commit 9990ddf47d41 ("net: tunnel: make
> skb_vlan_inet_prepare() return drop reasons") like mentioned here:
>
> https://lore.kernel.org/netdev/DGAR3PO1D33S.1TI7W7U4SPTOG@suse.com/
>
> It seems that that commit 81c734dae203 ("ip6_tunnel: use
> skb_vlan_inet_prepare() in __ip6_tnl_rcv()") uses the new
> skb_vlan_inet_prepare added in v6.13, which broke 6.12.

Greg Kroah-Hartman backported my patch to 6.12 LTS, but forgot that a
prior patch
from Menglong Dong inverted the skb_vlan_inet_prepare() return code.

Greg, can you backport the following to 6.12 LTS ?

Thanks.

commit 9990ddf47d4168088e2246c3d418bf526e40830d
Author: Menglong Dong <menglong8.dong@gmail.com>
Date:   Wed Oct 9 10:28:21 2024 +0800

    net: tunnel: make skb_vlan_inet_prepare() return drop reasons

    Make skb_vlan_inet_prepare return the skb drop reasons, which is just
    what pskb_may_pull_reason() returns. Meanwhile, adjust all the call of
    it.

    Signed-off-by: Menglong Dong <dongml2@chinatelecom.cn>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>

Re: [PATCH net] ip6_tunnel: use skb_vlan_inet_prepare() in __ip6_tnl_rcv()

[Greg Kroah-Hartman]

On Tue, Feb 10, 2026 at 01:56:14PM +0100, Eric Dumazet wrote:
> On Tue, Feb 10, 2026 at 1:42 PM Ricardo B. Marlière <rbm@suse.com> wrote:
> >
> > On Fri Jan 30, 2026 at 9:00 AM -03, Eric Dumazet wrote:
> > > On Fri, Jan 30, 2026 at 5:15 AM Hirokazu MORIKAWA <morikw2@gmail.com> wrote:
> > >>
> > >> [REGRESSION] ip6_tunnel: IPv4 traffic broken in MAP-E/DS-Lite since
> > >> commit df5ffde96693
> > >>
> > >> Hi,
> > >> I am reporting a regression in the IPv6 tunneling stack (MAP-E and
> > >> DS-Lite) introduced in kernel 6.12.67.
> > >>
> > >> [Description] After upgrading the kernel from 6.12.66 to 6.12.67 in
> > >> the OpenWrt snapshot, IPv4 packets can no longer be sent to the
> > >> external network via MAP-E or DS-Lite interfaces.
> > >> [Environment]
> > >> * Hardware: FriendlyElec NanoPi R6C
> > >> * OS: OpenWrt snapshot
> > >> * Kernel version: 6.12.67 (Broken), 6.12.66 (Working)
> > >> * Protocol: MAP-E and DS-Lite
> > >> [Culprit] By bisecting/reverting individual commits, I have identified
> > >> that the following commit is responsible for this issue:
> > >> "ip6_tunnel: use skb_vlan_inet_prepare() in __ip6_tnl_rcv()" (Link to
> > >> the patch: https://lore.kernel.org/netdev/20260107163109.4188620-1-edumazet@google.com/)
> > >> Reverting this specific commit on top of kernel 6.12.67 restores
> > >> normal connectivity for both MAP-E and DS-Lite.
> > >> [Steps to reproduce]
> > >> 1. Set up a MAP-E or DS-Lite connection on kernel 6.12.67.
> > >> 2. Attempt to send IPv4 traffic (e.g., ping 8.8.8.8).
> > >> 3. The packets fail to reach the destination.
> > >
> > > Thanks for the report.
> > >
> > > Can you provide detailed instructions ?
> > >
> > > Apparently none of our selftests caught the issue, it would be great to add one.
> >
> > Perhaps l2_tos_ttl_inherit.sh [1]? I've seen a timeout in this test that
> > went away after testing commit 9990ddf47d41 ("net: tunnel: make
> > skb_vlan_inet_prepare() return drop reasons") like mentioned here:
> >
> > https://lore.kernel.org/netdev/DGAR3PO1D33S.1TI7W7U4SPTOG@suse.com/
> >
> > It seems that that commit 81c734dae203 ("ip6_tunnel: use
> > skb_vlan_inet_prepare() in __ip6_tnl_rcv()") uses the new
> > skb_vlan_inet_prepare added in v6.13, which broke 6.12.
> 
> Greg Kroah-Hartman backported my patch to 6.12 LTS, but forgot that a
> prior patch
> from Menglong Dong inverted the skb_vlan_inet_prepare() return code.
> 
> Greg, can you backport the following to 6.12 LTS ?
> 
> Thanks.
> 
> commit 9990ddf47d4168088e2246c3d418bf526e40830d
> Author: Menglong Dong <menglong8.dong@gmail.com>
> Date:   Wed Oct 9 10:28:21 2024 +0800
> 
>     net: tunnel: make skb_vlan_inet_prepare() return drop reasons
> 
>     Make skb_vlan_inet_prepare return the skb drop reasons, which is just
>     what pskb_may_pull_reason() returns. Meanwhile, adjust all the call of
>     it.
> 
>     Signed-off-by: Menglong Dong <dongml2@chinatelecom.cn>
>     Reviewed-by: Simon Horman <horms@kernel.org>
>     Signed-off-by: David S. Miller <davem@davemloft.net>

Sure, will do after this next round of releases goes out.

greg k-h

Re: [PATCH net] ip6_tunnel: use skb_vlan_inet_prepare() in __ip6_tnl_rcv()

[hammer065]

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@ipv6-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

Re: [PATCH net] ip6_tunnel: use skb_vlan_inet_prepare() in __ip6_tnl_rcv()

[Hirokazu MORIKAWA]

> Can you provide detailed instructions ?

It is configured as a router.
OpenWrt isssue link: https://github.com/openwrt/openwrt/issues/21737

> I have no idea what MAP-E or DS-Lite are.
MAP-E (RFC 7597) and DS-Lite (RFC 6333) are IPv6 transition
technologies used to tunnel IPv4 traffic over IPv6-only networks. They
are widely deployed by ISPs, particularly in Japan, to handle the
shortage of IPv4 addresses.

I have packet captures from 6.12.67 (Broken) and 6.12.66 (Working).
The ICMP request-reply appears normal.
However, the ping command does not return a reply.

[PATCH net] ip6_tunnel: use skb_vlan_inet_prepare() in __ip6_tnl_rcv()

[Eric Dumazet]

Blamed commit did not take care of VLAN encapsulations
as spotted by syzbot [1].

Use skb_vlan_inet_prepare() instead of pskb_inet_may_pull().

[1]
 BUG: KMSAN: uninit-value in __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline]
 BUG: KMSAN: uninit-value in INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline]
 BUG: KMSAN: uninit-value in IP6_ECN_decapsulate+0x7a8/0x1fa0 include/net/inet_ecn.h:321
  __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline]
  INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline]
  IP6_ECN_decapsulate+0x7a8/0x1fa0 include/net/inet_ecn.h:321
  ip6ip6_dscp_ecn_decapsulate+0x16f/0x1b0 net/ipv6/ip6_tunnel.c:729
  __ip6_tnl_rcv+0xed9/0x1b50 net/ipv6/ip6_tunnel.c:860
  ip6_tnl_rcv+0xc3/0x100 net/ipv6/ip6_tunnel.c:903
 gre_rcv+0x1529/0x1b90 net/ipv6/ip6_gre.c:-1
  ip6_protocol_deliver_rcu+0x1c89/0x2c60 net/ipv6/ip6_input.c:438
  ip6_input_finish+0x1f4/0x4a0 net/ipv6/ip6_input.c:489
  NF_HOOK include/linux/netfilter.h:318 [inline]
  ip6_input+0x9c/0x330 net/ipv6/ip6_input.c:500
  ip6_mc_input+0x7ca/0xc10 net/ipv6/ip6_input.c:590
  dst_input include/net/dst.h:474 [inline]
  ip6_rcv_finish+0x958/0x990 net/ipv6/ip6_input.c:79
  NF_HOOK include/linux/netfilter.h:318 [inline]
  ipv6_rcv+0xf1/0x3c0 net/ipv6/ip6_input.c:311
  __netif_receive_skb_one_core net/core/dev.c:6139 [inline]
  __netif_receive_skb+0x1df/0xac0 net/core/dev.c:6252
  netif_receive_skb_internal net/core/dev.c:6338 [inline]
  netif_receive_skb+0x57/0x630 net/core/dev.c:6397
  tun_rx_batched+0x1df/0x980 drivers/net/tun.c:1485
  tun_get_user+0x5c0e/0x6c60 drivers/net/tun.c:1953
  tun_chr_write_iter+0x3e9/0x5c0 drivers/net/tun.c:1999
  new_sync_write fs/read_write.c:593 [inline]
  vfs_write+0xbe2/0x15d0 fs/read_write.c:686
  ksys_write fs/read_write.c:738 [inline]
  __do_sys_write fs/read_write.c:749 [inline]
  __se_sys_write fs/read_write.c:746 [inline]
  __x64_sys_write+0x1fb/0x4d0 fs/read_write.c:746
  x64_sys_call+0x30ab/0x3e70 arch/x86/include/generated/asm/syscalls_64.h:2
  do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
  do_syscall_64+0xd3/0xf80 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Uninit was created at:
  slab_post_alloc_hook mm/slub.c:4960 [inline]
  slab_alloc_node mm/slub.c:5263 [inline]
  kmem_cache_alloc_node_noprof+0x9e7/0x17a0 mm/slub.c:5315
  kmalloc_reserve+0x13c/0x4b0 net/core/skbuff.c:586
  __alloc_skb+0x805/0x1040 net/core/skbuff.c:690
  alloc_skb include/linux/skbuff.h:1383 [inline]
  alloc_skb_with_frags+0xc5/0xa60 net/core/skbuff.c:6712
  sock_alloc_send_pskb+0xacc/0xc60 net/core/sock.c:2995
  tun_alloc_skb drivers/net/tun.c:1461 [inline]
  tun_get_user+0x1142/0x6c60 drivers/net/tun.c:1794
  tun_chr_write_iter+0x3e9/0x5c0 drivers/net/tun.c:1999
  new_sync_write fs/read_write.c:593 [inline]
  vfs_write+0xbe2/0x15d0 fs/read_write.c:686
  ksys_write fs/read_write.c:738 [inline]
  __do_sys_write fs/read_write.c:749 [inline]
  __se_sys_write fs/read_write.c:746 [inline]
  __x64_sys_write+0x1fb/0x4d0 fs/read_write.c:746
  x64_sys_call+0x30ab/0x3e70 arch/x86/include/generated/asm/syscalls_64.h:2
  do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
  do_syscall_64+0xd3/0xf80 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

CPU: 0 UID: 0 PID: 6465 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(none)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025

Fixes: 8d975c15c0cd ("ip6_tunnel: make sure to pull inner header in __ip6_tnl_rcv()")
Reported-by: syzbot+d4dda070f833dc5dc89a@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/netdev/695e88b2.050a0220.1c677c.036d.GAE@google.com/T/#u
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
 net/ipv6/ip6_tunnel.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
index 6405072050e0ef7521ca1fdddc4a0252e2159d2a..c1f39735a23676174839814b7c27e8b690845508 100644
--- a/net/ipv6/ip6_tunnel.c
+++ b/net/ipv6/ip6_tunnel.c
@@ -844,7 +844,7 @@ static int __ip6_tnl_rcv(struct ip6_tnl *tunnel, struct sk_buff *skb,
 
 	skb_reset_network_header(skb);
 
-	if (!pskb_inet_may_pull(skb)) {
+	if (skb_vlan_inet_prepare(skb, true)) {
 		DEV_STATS_INC(tunnel->dev, rx_length_errors);
 		DEV_STATS_INC(tunnel->dev, rx_errors);
 		goto drop;
-- 
2.52.0.351.gbe84eed79e-goog

Re: [PATCH net] ip6_tunnel: use skb_vlan_inet_prepare() in __ip6_tnl_rcv()

[patchwork-bot+netdevbpf]

Hello:

This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:

On Wed,  7 Jan 2026 16:31:09 +0000 you wrote:
> Blamed commit did not take care of VLAN encapsulations
> as spotted by syzbot [1].
> 
> Use skb_vlan_inet_prepare() instead of pskb_inet_may_pull().
> 
> [1]
>  BUG: KMSAN: uninit-value in __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline]
>  BUG: KMSAN: uninit-value in INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline]
>  BUG: KMSAN: uninit-value in IP6_ECN_decapsulate+0x7a8/0x1fa0 include/net/inet_ecn.h:321
>   __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline]
>   INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline]
>   IP6_ECN_decapsulate+0x7a8/0x1fa0 include/net/inet_ecn.h:321
>   ip6ip6_dscp_ecn_decapsulate+0x16f/0x1b0 net/ipv6/ip6_tunnel.c:729
>   __ip6_tnl_rcv+0xed9/0x1b50 net/ipv6/ip6_tunnel.c:860
>   ip6_tnl_rcv+0xc3/0x100 net/ipv6/ip6_tunnel.c:903
>  gre_rcv+0x1529/0x1b90 net/ipv6/ip6_gre.c:-1
>   ip6_protocol_deliver_rcu+0x1c89/0x2c60 net/ipv6/ip6_input.c:438
>   ip6_input_finish+0x1f4/0x4a0 net/ipv6/ip6_input.c:489
>   NF_HOOK include/linux/netfilter.h:318 [inline]
>   ip6_input+0x9c/0x330 net/ipv6/ip6_input.c:500
>   ip6_mc_input+0x7ca/0xc10 net/ipv6/ip6_input.c:590
>   dst_input include/net/dst.h:474 [inline]
>   ip6_rcv_finish+0x958/0x990 net/ipv6/ip6_input.c:79
>   NF_HOOK include/linux/netfilter.h:318 [inline]
>   ipv6_rcv+0xf1/0x3c0 net/ipv6/ip6_input.c:311
>   __netif_receive_skb_one_core net/core/dev.c:6139 [inline]
>   __netif_receive_skb+0x1df/0xac0 net/core/dev.c:6252
>   netif_receive_skb_internal net/core/dev.c:6338 [inline]
>   netif_receive_skb+0x57/0x630 net/core/dev.c:6397
>   tun_rx_batched+0x1df/0x980 drivers/net/tun.c:1485
>   tun_get_user+0x5c0e/0x6c60 drivers/net/tun.c:1953
>   tun_chr_write_iter+0x3e9/0x5c0 drivers/net/tun.c:1999
>   new_sync_write fs/read_write.c:593 [inline]
>   vfs_write+0xbe2/0x15d0 fs/read_write.c:686
>   ksys_write fs/read_write.c:738 [inline]
>   __do_sys_write fs/read_write.c:749 [inline]
>   __se_sys_write fs/read_write.c:746 [inline]
>   __x64_sys_write+0x1fb/0x4d0 fs/read_write.c:746
>   x64_sys_call+0x30ab/0x3e70 arch/x86/include/generated/asm/syscalls_64.h:2
>   do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
>   do_syscall_64+0xd3/0xf80 arch/x86/entry/syscall_64.c:94
>  entry_SYSCALL_64_after_hwframe+0x77/0x7f
> 
> [...]

Here is the summary with links:
  - [net] ip6_tunnel: use skb_vlan_inet_prepare() in __ip6_tnl_rcv()
    https://git.kernel.org/netdev/net/c/81c734dae203

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html