[PATCH v1 net 0/5] ip: Fix warning in pskb_may_pull_reason() for tunnel devices.

[PATCH v1 net 0/5] ip: Fix warning in pskb_may_pull_reason() for tunnel devices.

[Kuniyuki Iwashima]

syzkaller reported warnings in pskb_may_pull_reason(), which was
triggered by a VLAN packet sent over tunnel devices.

This series fixes the warning for sit, vti, vti6, ipip, and ip6tnl.


Kuniyuki Iwashima (5):
  sit: Pull header after checking skb->protocol in sit_tunnel_xmit().
  vti: Pull header after checking skb->protocol in vti_tunnel_xmit().
  ip6_vti: Pull header after checking skb->protocol in vti6_tnl_xmit().
  ipip: Pull header after checking skb->protocol in ipip_tunnel_xmit().
  ip6_tunnel: Pull header after checking skb->protocol in
    ip6_tnl_start_xmit().

 net/ipv4/ip_vti.c     | 9 ++++++---
 net/ipv4/ipip.c       | 6 +++---
 net/ipv6/ip6_tunnel.c | 9 ++++++---
 net/ipv6/ip6_vti.c    | 9 ++++++---
 net/ipv6/sit.c        | 9 ++++++---
 5 files changed, 27 insertions(+), 15 deletions(-)

-- 
2.30.2

[PATCH v1 net 1/5] sit: Pull header after checking skb->protocol in sit_tunnel_xmit().

[Kuniyuki Iwashima]

syzkaller crafted a GSO packet of ETH_P_8021AD + ETH_P_NSH and sent it
over sit0.

After nsh_gso_segment(), skb->data - skb->head was 138, on the other
hand, skb->network_header was 128.

Later, sit_tunnel_xmit() called pskb_inet_may_pull() for the skb, and
it caused underflow and triggered the warning in pskb_may_pull_reason().

  pskb_network_may_pull(skb, nhlen)
  `- pskb_may_pull(skb, skb_network_offset(skb) + nhlen)

  -> skb_network_offset(skb) + nhlen
   = skb_network_offset(skb) + 0 (because skb->protocol is not IPv4/IPv6)
   = skb_network_header(skb) - skb->data
   = skb->head + skb->network_header - skb->data
   = 128 - 138
   = -10

Let's check skb->protocol before pulling the next header in
sit_tunnel_xmit().

WARNING: CPU: 1 PID: 5300 at include/linux/skbuff.h:2740 pskb_may_pull_reason include/linux/skbuff.h:2740 [inline]
WARNING: CPU: 1 PID: 5300 at include/linux/skbuff.h:2740 pskb_may_pull include/linux/skbuff.h:2756 [inline]
WARNING: CPU: 1 PID: 5300 at include/linux/skbuff.h:2740 pskb_network_may_pull include/linux/skbuff.h:3077 [inline]
WARNING: CPU: 1 PID: 5300 at include/linux/skbuff.h:2740 pskb_inet_may_pull include/net/ip_tunnels.h:361 [inline]
WARNING: CPU: 1 PID: 5300 at include/linux/skbuff.h:2740 sit_tunnel_xmit+0x1080/0x1fd8 net/ipv6/sit.c:1068
Modules linked in:
CPU: 1 PID: 5300 Comm: syz-executor.5 Not tainted 6.8.0-12821-g537c2e91d354-dirty #11
Hardware name: linux,dummy-virt (DT)
pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : pskb_may_pull_reason include/linux/skbuff.h:2740 [inline]
pc : pskb_may_pull include/linux/skbuff.h:2756 [inline]
pc : pskb_network_may_pull include/linux/skbuff.h:3077 [inline]
pc : pskb_inet_may_pull include/net/ip_tunnels.h:361 [inline]
pc : sit_tunnel_xmit+0x1080/0x1fd8 net/ipv6/sit.c:1068
lr : pskb_may_pull_reason include/linux/skbuff.h:2740 [inline]
lr : pskb_may_pull include/linux/skbuff.h:2756 [inline]
lr : pskb_network_may_pull include/linux/skbuff.h:3077 [inline]
lr : pskb_inet_may_pull include/net/ip_tunnels.h:361 [inline]
lr : sit_tunnel_xmit+0x1080/0x1fd8 net/ipv6/sit.c:1068
sp : ffff8000aa017260
x29: ffff8000aa0173e0 x28: ffff00000cd0c000 x27: ffff000046200080
x26: ffff700015402e64 x25: 00000000fffffff6 x24: 1fffe00009835b7f
x23: dfff800000000000 x22: ffff00004c1adbf4 x21: ffff00004c1adbf8
x20: ffff00004c1adb40 x19: 1fffe00009835b7e x18: ffff800086d72d10
x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000001
x14: 1fffe0000a15c217 x13: 0000000000000000 x12: ffff8000aa017320
x11: 0000000000040000 x10: 0000000000000b86 x9 : ffff8000a2639000
x8 : 0000000000000b87 x7 : 0000000000000001 x6 : 0000000000000001
x5 : ffff8000aa016c98 x4 : ffff800086d8b120 x3 : ffff800083f7f7d4
x2 : 0000000000000001 x1 : 00000000fffffff6 x0 : 0000000000000000
Call trace:
 pskb_may_pull_reason include/linux/skbuff.h:2740 [inline]
 pskb_may_pull include/linux/skbuff.h:2756 [inline]
 pskb_network_may_pull include/linux/skbuff.h:3077 [inline]
 pskb_inet_may_pull include/net/ip_tunnels.h:361 [inline]
 sit_tunnel_xmit+0x1080/0x1fd8 net/ipv6/sit.c:1068
 __netdev_start_xmit include/linux/netdevice.h:4903 [inline]
 netdev_start_xmit include/linux/netdevice.h:4917 [inline]
 xmit_one net/core/dev.c:3531 [inline]
 dev_hard_start_xmit+0x1a0/0x370 net/core/dev.c:3547
 __dev_queue_xmit+0x12e8/0x2b04 net/core/dev.c:4335
 dev_queue_xmit include/linux/netdevice.h:3091 [inline]
 packet_xmit+0x6c/0x31c net/packet/af_packet.c:276
 packet_snd net/packet/af_packet.c:3081 [inline]
 packet_sendmsg+0x3818/0x4e50 net/packet/af_packet.c:3113
 sock_sendmsg_nosec net/socket.c:730 [inline]
 __sock_sendmsg net/socket.c:745 [inline]
 __sys_sendto+0x324/0x470 net/socket.c:2191
 __do_sys_sendto net/socket.c:2203 [inline]
 __se_sys_sendto net/socket.c:2199 [inline]
 __arm64_sys_sendto+0xd8/0xf8 net/socket.c:2199
 __invoke_syscall arch/arm64/kernel/syscall.c:34 [inline]
 invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:48
 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:133
 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:152
 el0_svc+0x30/0x78 arch/arm64/kernel/entry-common.c:712
 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730
 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598

Reported-by: syzkaller <syzkaller@googlegroups.com>
Fixes: cb9f1b783850 ("ip: validate header length on virtual device xmit")
Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
---
 net/ipv6/sit.c | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/net/ipv6/sit.c b/net/ipv6/sit.c
index 655c9b1a19b8..b83c28369d46 100644
--- a/net/ipv6/sit.c
+++ b/net/ipv6/sit.c
@@ -1065,14 +1065,17 @@ static netdev_tx_t sit_tunnel_xmit__(struct sk_buff *skb,
 static netdev_tx_t sit_tunnel_xmit(struct sk_buff *skb,
 				   struct net_device *dev)
 {
-	if (!pskb_inet_may_pull(skb))
-		goto tx_err;
-
 	switch (skb->protocol) {
 	case htons(ETH_P_IP):
+		if (!pskb_network_may_pull(skb, sizeof(struct iphdr)))
+			goto tx_err;
+
 		sit_tunnel_xmit__(skb, dev, IPPROTO_IPIP);
 		break;
 	case htons(ETH_P_IPV6):
+		if (!pskb_network_may_pull(skb, sizeof(struct ipv6hdr)))
+			goto tx_err;
+
 		ipip6_tunnel_xmit(skb, dev);
 		break;
 #if IS_ENABLED(CONFIG_MPLS)
-- 
2.30.2

[PATCH v1 net 2/5] vti: Pull header after checking skb->protocol in vti_tunnel_xmit().

[Kuniyuki Iwashima]

syzkaller demonstrated the underflow in pskb_network_may_pull()
by sending a crafted VLAN packet over the tunnel device.

Let's check skb->protocol before pulling the next header in
vti_tunnel_xmit().

WARNING: CPU: 1 PID: 4534 at include/linux/skbuff.h:2740 pskb_may_pull_reason include/linux/skbuff.h:2740 [inline]
WARNING: CPU: 1 PID: 4534 at include/linux/skbuff.h:2740 pskb_may_pull include/linux/skbuff.h:2756 [inline]
WARNING: CPU: 1 PID: 4534 at include/linux/skbuff.h:2740 pskb_network_may_pull include/linux/skbuff.h:3077 [inline]
WARNING: CPU: 1 PID: 4534 at include/linux/skbuff.h:2740 pskb_inet_may_pull include/net/ip_tunnels.h:361 [inline]
WARNING: CPU: 1 PID: 4534 at include/linux/skbuff.h:2740 vti_tunnel_xmit+0xd48/0x14b4 net/ipv4/ip_vti.c:283
Modules linked in:
CPU: 1 PID: 4534 Comm: syz-executor.1 Not tainted 6.8.0-12821-g537c2e91d354-dirty #11
Hardware name: linux,dummy-virt (DT)
pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : pskb_may_pull_reason include/linux/skbuff.h:2740 [inline]
pc : pskb_may_pull include/linux/skbuff.h:2756 [inline]
pc : pskb_network_may_pull include/linux/skbuff.h:3077 [inline]
pc : pskb_inet_may_pull include/net/ip_tunnels.h:361 [inline]
pc : vti_tunnel_xmit+0xd48/0x14b4 net/ipv4/ip_vti.c:283
lr : pskb_may_pull_reason include/linux/skbuff.h:2740 [inline]
lr : pskb_may_pull include/linux/skbuff.h:2756 [inline]
lr : pskb_network_may_pull include/linux/skbuff.h:3077 [inline]
lr : pskb_inet_may_pull include/net/ip_tunnels.h:361 [inline]
lr : vti_tunnel_xmit+0xd48/0x14b4 net/ipv4/ip_vti.c:283
sp : ffff8000a99372a0
x29: ffff8000a99373e0 x28: ffff00000d188838 x27: ffff700015326e64
x26: ffff000061930080 x25: dfff800000000000 x24: ffff8000a9937320
x23: 0000000000000000 x22: ffff00000d188834 x21: 00000000fffffff6
x20: ffff00000d188780 x19: ffff000017580000 x18: ffff800086d72d10
x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000001
x14: 1fffe000029ce017 x13: 0000000000000000 x12: 0000000000000001
x11: 0000000000040000 x10: 0000000000000b7f x9 : ffff80008a3fa000
x8 : 0000000000000b80 x7 : 0000000000000001 x6 : 0000000000000001
x5 : ffff8000a9936c98 x4 : ffff800086d8b120 x3 : ffff800083f7f7d4
x2 : 0000000000000001 x1 : 00000000fffffff6 x0 : 0000000000000000
Call trace:
 pskb_may_pull_reason include/linux/skbuff.h:2740 [inline]
 pskb_may_pull include/linux/skbuff.h:2756 [inline]
 pskb_network_may_pull include/linux/skbuff.h:3077 [inline]
 pskb_inet_may_pull include/net/ip_tunnels.h:361 [inline]
 vti_tunnel_xmit+0xd48/0x14b4 net/ipv4/ip_vti.c:283
 __netdev_start_xmit include/linux/netdevice.h:4903 [inline]
 netdev_start_xmit include/linux/netdevice.h:4917 [inline]
 xmit_one net/core/dev.c:3531 [inline]
 dev_hard_start_xmit+0x1a0/0x370 net/core/dev.c:3547
 __dev_queue_xmit+0x12e8/0x2b04 net/core/dev.c:4335
 dev_queue_xmit include/linux/netdevice.h:3091 [inline]
 packet_xmit+0x6c/0x31c net/packet/af_packet.c:276
 packet_snd net/packet/af_packet.c:3081 [inline]
 packet_sendmsg+0x3818/0x4e50 net/packet/af_packet.c:3113
 sock_sendmsg_nosec net/socket.c:730 [inline]
 __sock_sendmsg net/socket.c:745 [inline]
 __sys_sendto+0x324/0x470 net/socket.c:2191
 __do_sys_sendto net/socket.c:2203 [inline]
 __se_sys_sendto net/socket.c:2199 [inline]
 __arm64_sys_sendto+0xd8/0xf8 net/socket.c:2199
 __invoke_syscall arch/arm64/kernel/syscall.c:34 [inline]
 invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:48
 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:133
 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:152
 el0_svc+0x30/0x78 arch/arm64/kernel/entry-common.c:712
 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730
 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598

Reported-by: syzkaller <syzkaller@googlegroups.com>
Fixes: cb9f1b783850 ("ip: validate header length on virtual device xmit")
Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
---
 net/ipv4/ip_vti.c | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/net/ipv4/ip_vti.c b/net/ipv4/ip_vti.c
index ee587adb169f..8070d0c440f6 100644
--- a/net/ipv4/ip_vti.c
+++ b/net/ipv4/ip_vti.c
@@ -280,17 +280,20 @@ static netdev_tx_t vti_tunnel_xmit(struct sk_buff *skb, struct net_device *dev)
 	struct ip_tunnel *tunnel = netdev_priv(dev);
 	struct flowi fl;
 
-	if (!pskb_inet_may_pull(skb))
-		goto tx_err;
-
 	memset(&fl, 0, sizeof(fl));
 
 	switch (skb->protocol) {
 	case htons(ETH_P_IP):
+		if (!pskb_network_may_pull(skb, sizeof(struct iphdr)))
+			goto tx_err;
+
 		memset(IPCB(skb), 0, sizeof(*IPCB(skb)));
 		xfrm_decode_session(dev_net(dev), skb, &fl, AF_INET);
 		break;
 	case htons(ETH_P_IPV6):
+		if (!pskb_network_may_pull(skb, sizeof(struct ipv6hdr)))
+			goto tx_err;
+
 		memset(IP6CB(skb), 0, sizeof(*IP6CB(skb)));
 		xfrm_decode_session(dev_net(dev), skb, &fl, AF_INET6);
 		break;
-- 
2.30.2

[PATCH v1 net 3/5] ip6_vti: Pull header after checking skb->protocol in vti6_tnl_xmit().

[Kuniyuki Iwashima]

syzkaller demonstrated the underflow in pskb_network_may_pull()
by sending a crafted VLAN packet over the tunnel device.

Let's check skb->protocol before pulling the next header in
vti6_tnl_xmit().

WARNING: CPU: 0 PID: 722 at include/linux/skbuff.h:2740 pskb_may_pull_reason include/linux/skbuff.h:2740 [inline]
WARNING: CPU: 0 PID: 722 at include/linux/skbuff.h:2740 pskb_may_pull include/linux/skbuff.h:2756 [inline]
WARNING: CPU: 0 PID: 722 at include/linux/skbuff.h:2740 pskb_network_may_pull include/linux/skbuff.h:3077 [inline]
WARNING: CPU: 0 PID: 722 at include/linux/skbuff.h:2740 pskb_inet_may_pull include/net/ip_tunnels.h:361 [inline]
WARNING: CPU: 0 PID: 722 at include/linux/skbuff.h:2740 vti6_tnl_xmit+0x100c/0x16c0 net/ipv6/ip6_vti.c:560
Modules linked in:
CPU: 0 PID: 722 Comm: syz-executor.3 Not tainted 6.8.0-12821-g537c2e91d354-dirty #11
Hardware name: linux,dummy-virt (DT)
pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : pskb_may_pull_reason include/linux/skbuff.h:2740 [inline]
pc : pskb_may_pull include/linux/skbuff.h:2756 [inline]
pc : pskb_network_may_pull include/linux/skbuff.h:3077 [inline]
pc : pskb_inet_may_pull include/net/ip_tunnels.h:361 [inline]
pc : vti6_tnl_xmit+0x100c/0x16c0 net/ipv6/ip6_vti.c:560
lr : pskb_may_pull_reason include/linux/skbuff.h:2740 [inline]
lr : pskb_may_pull include/linux/skbuff.h:2756 [inline]
lr : pskb_network_may_pull include/linux/skbuff.h:3077 [inline]
lr : pskb_inet_may_pull include/net/ip_tunnels.h:361 [inline]
lr : vti6_tnl_xmit+0x100c/0x16c0 net/ipv6/ip6_vti.c:560
sp : ffff8000a86d7280
x29: ffff8000a86d73e0 x28: ffff7000150dae64 x27: ffff8000a86d7320
x26: ffff00004fdd0010 x25: dfff800000000000 x24: 00000000fffffff6
x23: ffff00000a0ae478 x22: ffff00000a0ae498 x21: ffff00000a0ae474
x20: ffff00000a0ae3c0 x19: ffff0000178d6000 x18: ffff800086d72d10
x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000001
x14: 1fffe0000958b817 x13: 0000000000000000 x12: 0000000000000001
x11: 0000000000040000 x10: 0000000000000b8a x9 : ffff80008e699000
x8 : 0000000000000b8b x7 : 0000000000000001 x6 : 0000000000000001
x5 : ffff8000a86d6c98 x4 : ffff800086d8b120 x3 : ffff800083f7f7d4
x2 : 0000000000000001 x1 : 00000000fffffff6 x0 : 0000000000000000
Call trace:
 pskb_may_pull_reason include/linux/skbuff.h:2740 [inline]
 pskb_may_pull include/linux/skbuff.h:2756 [inline]
 pskb_network_may_pull include/linux/skbuff.h:3077 [inline]
 pskb_inet_may_pull include/net/ip_tunnels.h:361 [inline]
 vti6_tnl_xmit+0x100c/0x16c0 net/ipv6/ip6_vti.c:560
 __netdev_start_xmit include/linux/netdevice.h:4903 [inline]
 netdev_start_xmit include/linux/netdevice.h:4917 [inline]
 xmit_one net/core/dev.c:3531 [inline]
 dev_hard_start_xmit+0x1a0/0x370 net/core/dev.c:3547
 __dev_queue_xmit+0x12e8/0x2b04 net/core/dev.c:4335
 dev_queue_xmit include/linux/netdevice.h:3091 [inline]
 packet_xmit+0x6c/0x31c net/packet/af_packet.c:276
 packet_snd net/packet/af_packet.c:3081 [inline]
 packet_sendmsg+0x3818/0x4e50 net/packet/af_packet.c:3113
 sock_sendmsg_nosec net/socket.c:730 [inline]
 __sock_sendmsg net/socket.c:745 [inline]
 __sys_sendto+0x324/0x470 net/socket.c:2191
 __do_sys_sendto net/socket.c:2203 [inline]
 __se_sys_sendto net/socket.c:2199 [inline]
 __arm64_sys_sendto+0xd8/0xf8 net/socket.c:2199
 __invoke_syscall arch/arm64/kernel/syscall.c:34 [inline]
 invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:48
 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:133
 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:152
 el0_svc+0x30/0x78 arch/arm64/kernel/entry-common.c:712
 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730
 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598

Reported-by: syzkaller <syzkaller@googlegroups.com>
Fixes: cb9f1b783850 ("ip: validate header length on virtual device xmit")
Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
---
 net/ipv6/ip6_vti.c | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/net/ipv6/ip6_vti.c b/net/ipv6/ip6_vti.c
index 7f4f976aa24a..98c738eb6166 100644
--- a/net/ipv6/ip6_vti.c
+++ b/net/ipv6/ip6_vti.c
@@ -557,13 +557,13 @@ vti6_tnl_xmit(struct sk_buff *skb, struct net_device *dev)
 	struct flowi fl;
 	int ret;
 
-	if (!pskb_inet_may_pull(skb))
-		goto tx_err;
-
 	memset(&fl, 0, sizeof(fl));
 
 	switch (skb->protocol) {
 	case htons(ETH_P_IPV6):
+		if (!pskb_network_may_pull(skb, sizeof(struct ipv6hdr)))
+			goto tx_err;
+
 		if ((t->parms.proto != IPPROTO_IPV6 && t->parms.proto != 0) ||
 		    vti6_addr_conflict(t, ipv6_hdr(skb)))
 			goto tx_err;
@@ -572,6 +572,9 @@ vti6_tnl_xmit(struct sk_buff *skb, struct net_device *dev)
 		xfrm_decode_session(dev_net(dev), skb, &fl, AF_INET6);
 		break;
 	case htons(ETH_P_IP):
+		if (!pskb_network_may_pull(skb, sizeof(struct iphdr)))
+			goto tx_err;
+
 		memset(IPCB(skb), 0, sizeof(*IPCB(skb)));
 		xfrm_decode_session(dev_net(dev), skb, &fl, AF_INET);
 		break;
-- 
2.30.2

[PATCH v1 net 4/5] ipip: Pull header after checking skb->protocol in ipip_tunnel_xmit().

[Kuniyuki Iwashima]

syzkaller demonstrated the underflow in pskb_network_may_pull()
by sending a crafted VLAN packet over the tunnel device.

Let's check skb->protocol before pulling the next header in
ipip_tunnel_xmit().

WARNING: CPU: 0 PID: 4406 at include/linux/skbuff.h:2740 pskb_may_pull_reason include/linux/skbuff.h:2740 [inline]
WARNING: CPU: 0 PID: 4406 at include/linux/skbuff.h:2740 pskb_may_pull include/linux/skbuff.h:2756 [inline]
WARNING: CPU: 0 PID: 4406 at include/linux/skbuff.h:2740 pskb_network_may_pull include/linux/skbuff.h:3077 [inline]
WARNING: CPU: 0 PID: 4406 at include/linux/skbuff.h:2740 pskb_inet_may_pull include/net/ip_tunnels.h:361 [inline]
WARNING: CPU: 0 PID: 4406 at include/linux/skbuff.h:2740 ipip_tunnel_xmit+0x2d4/0x430 net/ipv4/ipip.c:281
Modules linked in:
CPU: 0 PID: 4406 Comm: syz-executor.1 Not tainted 6.8.0-12821-g537c2e91d354-dirty #11
Hardware name: linux,dummy-virt (DT)
pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : pskb_may_pull_reason include/linux/skbuff.h:2740 [inline]
pc : pskb_may_pull include/linux/skbuff.h:2756 [inline]
pc : pskb_network_may_pull include/linux/skbuff.h:3077 [inline]
pc : pskb_inet_may_pull include/net/ip_tunnels.h:361 [inline]
pc : ipip_tunnel_xmit+0x2d4/0x430 net/ipv4/ipip.c:281
lr : pskb_may_pull_reason include/linux/skbuff.h:2740 [inline]
lr : pskb_may_pull include/linux/skbuff.h:2756 [inline]
lr : pskb_network_may_pull include/linux/skbuff.h:3077 [inline]
lr : pskb_inet_may_pull include/net/ip_tunnels.h:361 [inline]
lr : ipip_tunnel_xmit+0x2d4/0x430 net/ipv4/ipip.c:281
sp : ffff8000a82673f0
x29: ffff8000a82673f0 x28: ffff00000fc24140 x27: ffff00006ab166ba
x26: 1fffe00001f8483e x25: dfff800000000000 x24: ffff00003b898080
x23: 0000000000000000 x22: 00000000fffffff6 x21: ffff00000fc241f4
x20: ffff00000fc24140 x19: ffff000046206000 x18: ffff800086d72d10
x17: 00000000008a008a x16: 008a4f8900000000 x15: 0000000000000001
x14: 1ffff00011028fbc x13: 0000000000000004 x12: 0000000000000001
x11: 0000000000040000 x10: 0000000000000f68 x9 : ffff80008d25a000
x8 : 0000000000000f69 x7 : ffff8000800477bc x6 : ffff8000800479b8
x5 : ffff0000687ca948 x4 : ffff8000a8267028 x3 : ffff800083f7f890
x2 : 0000000000000001 x1 : 00000000fffffff6 x0 : 0000000000000000
Call trace:
 pskb_may_pull_reason include/linux/skbuff.h:2740 [inline]
 pskb_may_pull include/linux/skbuff.h:2756 [inline]
 pskb_network_may_pull include/linux/skbuff.h:3077 [inline]
 pskb_inet_may_pull include/net/ip_tunnels.h:361 [inline]
 ipip_tunnel_xmit+0x2d4/0x430 net/ipv4/ipip.c:281
 __netdev_start_xmit include/linux/netdevice.h:4903 [inline]
 netdev_start_xmit include/linux/netdevice.h:4917 [inline]
 xmit_one net/core/dev.c:3531 [inline]
 dev_hard_start_xmit+0x1a0/0x370 net/core/dev.c:3547
 __dev_queue_xmit+0x12e8/0x2b04 net/core/dev.c:4335
 dev_queue_xmit include/linux/netdevice.h:3091 [inline]
 packet_xmit+0x6c/0x31c net/packet/af_packet.c:276
 packet_snd net/packet/af_packet.c:3081 [inline]
 packet_sendmsg+0x3818/0x4e50 net/packet/af_packet.c:3113
 sock_sendmsg_nosec net/socket.c:730 [inline]
 __sock_sendmsg net/socket.c:745 [inline]
 __sys_sendto+0x324/0x470 net/socket.c:2191
 __do_sys_sendto net/socket.c:2203 [inline]
 __se_sys_sendto net/socket.c:2199 [inline]
 __arm64_sys_sendto+0xd8/0xf8 net/socket.c:2199
 __invoke_syscall arch/arm64/kernel/syscall.c:34 [inline]
 invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:48
 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:133
 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:152
 el0_svc+0x30/0x78 arch/arm64/kernel/entry-common.c:712
 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730
 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598

Reported-by: syzkaller <syzkaller@googlegroups.com>
Fixes: cb9f1b783850 ("ip: validate header length on virtual device xmit")
Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
---
 net/ipv4/ipip.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/net/ipv4/ipip.c b/net/ipv4/ipip.c
index f2696eaadbe6..3f96364d65fd 100644
--- a/net/ipv4/ipip.c
+++ b/net/ipv4/ipip.c
@@ -278,11 +278,11 @@ static netdev_tx_t ipip_tunnel_xmit(struct sk_buff *skb,
 	const struct iphdr  *tiph = &tunnel->parms.iph;
 	u8 ipproto;
 
-	if (!pskb_inet_may_pull(skb))
-		goto tx_error;
-
 	switch (skb->protocol) {
 	case htons(ETH_P_IP):
+		if (!pskb_network_may_pull(skb, sizeof(struct iphdr)))
+			goto tx_error;
+
 		ipproto = IPPROTO_IPIP;
 		break;
 #if IS_ENABLED(CONFIG_MPLS)
-- 
2.30.2

[PATCH v1 net 5/5] ip6_tunnel: Pull header after checking skb->protocol in ip6_tnl_start_xmit().

[Kuniyuki Iwashima]

syzkaller demonstrated the underflow in pskb_network_may_pull()
by sending a crafted VLAN packet over tunnel devices: sit, ipip,
vti, and vti6.

The same warning will be triggered for ip6tnl, so let's check
skb->protocol before pulling the next header in ip6_tnl_start_xmit().

Fixes: cb9f1b783850 ("ip: validate header length on virtual device xmit")
Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
---
 net/ipv6/ip6_tunnel.c | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
index e9cc315832cb..81be7a5be6c5 100644
--- a/net/ipv6/ip6_tunnel.c
+++ b/net/ipv6/ip6_tunnel.c
@@ -1424,14 +1424,17 @@ ip6_tnl_start_xmit(struct sk_buff *skb, struct net_device *dev)
 	u8 ipproto;
 	int ret;
 
-	if (!pskb_inet_may_pull(skb))
-		goto tx_err;
-
 	switch (skb->protocol) {
 	case htons(ETH_P_IP):
+		if (!pskb_network_may_pull(skb, sizeof(struct iphdr)))
+			goto tx_err;
+
 		ipproto = IPPROTO_IPIP;
 		break;
 	case htons(ETH_P_IPV6):
+		if (!pskb_network_may_pull(skb, sizeof(struct ipv6hdr)))
+			goto tx_err;
+
 		if (ip6_tnl_addr_conflict(t, ipv6_hdr(skb)))
 			goto tx_err;
 		ipproto = IPPROTO_IPV6;
-- 
2.30.2

Re: [PATCH v1 net 1/5] sit: Pull header after checking skb->protocol in sit_tunnel_xmit().

[Jakub Kicinski]

On Mon, 15 Apr 2024 15:20:37 -0700 Kuniyuki Iwashima wrote:
> syzkaller crafted a GSO packet of ETH_P_8021AD + ETH_P_NSH and sent it
> over sit0.
> 
> After nsh_gso_segment(), skb->data - skb->head was 138, on the other
> hand, skb->network_header was 128.

is data offset > skb->network_header valid at this stage?
Can't we drop these packets instead?

Re: [PATCH v1 net 1/5] sit: Pull header after checking skb->protocol in sit_tunnel_xmit().

[Kuniyuki Iwashima]

From: Jakub Kicinski <kuba@kernel.org>
Date: Wed, 17 Apr 2024 19:04:32 -0700
> On Mon, 15 Apr 2024 15:20:37 -0700 Kuniyuki Iwashima wrote:
> > syzkaller crafted a GSO packet of ETH_P_8021AD + ETH_P_NSH and sent it
> > over sit0.
> > 
> > After nsh_gso_segment(), skb->data - skb->head was 138, on the other
> > hand, skb->network_header was 128.
> 
> is data offset > skb->network_header valid at this stage?
> Can't we drop these packets instead?

I think that needs another fix on the NSH side.

But even with that, we can still pass valid L2 skb to sit_tunnel_xmit()
and friends, and then we should just drop it there without calling
pskb_inet_may_pull() that should not be called for non-IP skb.

Re: [PATCH v1 net 1/5] sit: Pull header after checking skb->protocol in sit_tunnel_xmit().

[Eric Dumazet]

On Thu, Apr 18, 2024 at 5:32 AM Kuniyuki Iwashima <kuniyu@amazon.com> wrote:
>
> From: Jakub Kicinski <kuba@kernel.org>
> Date: Wed, 17 Apr 2024 19:04:32 -0700
> > On Mon, 15 Apr 2024 15:20:37 -0700 Kuniyuki Iwashima wrote:
> > > syzkaller crafted a GSO packet of ETH_P_8021AD + ETH_P_NSH and sent it
> > > over sit0.
> > >
> > > After nsh_gso_segment(), skb->data - skb->head was 138, on the other
> > > hand, skb->network_header was 128.
> >
> > is data offset > skb->network_header valid at this stage?
> > Can't we drop these packets instead?
>
> I think that needs another fix on the NSH side.
>
> But even with that, we can still pass valid L2 skb to sit_tunnel_xmit()
> and friends, and then we should just drop it there without calling
> pskb_inet_may_pull() that should not be called for non-IP skb.

I dislike this patch series. I had this NSH bug for a while in my
queue, the bug is in NSH.

Also I added skb_vlan_inet_prepare() recently for a similar issue.

Re: [PATCH v1 net 1/5] sit: Pull header after checking skb->protocol in sit_tunnel_xmit().

[Eric Dumazet]

On Thu, Apr 18, 2024 at 8:56 AM Eric Dumazet <edumazet@google.com> wrote:
>
> On Thu, Apr 18, 2024 at 5:32 AM Kuniyuki Iwashima <kuniyu@amazon.com> wrote:
> >
> > From: Jakub Kicinski <kuba@kernel.org>
> > Date: Wed, 17 Apr 2024 19:04:32 -0700
> > > On Mon, 15 Apr 2024 15:20:37 -0700 Kuniyuki Iwashima wrote:
> > > > syzkaller crafted a GSO packet of ETH_P_8021AD + ETH_P_NSH and sent it
> > > > over sit0.
> > > >
> > > > After nsh_gso_segment(), skb->data - skb->head was 138, on the other
> > > > hand, skb->network_header was 128.
> > >
> > > is data offset > skb->network_header valid at this stage?
> > > Can't we drop these packets instead?
> >
> > I think that needs another fix on the NSH side.
> >
> > But even with that, we can still pass valid L2 skb to sit_tunnel_xmit()
> > and friends, and then we should just drop it there without calling
> > pskb_inet_may_pull() that should not be called for non-IP skb.
>
> I dislike this patch series. I had this NSH bug for a while in my
> queue, the bug is in NSH.
>
> Also I added skb_vlan_inet_prepare() recently for a similar issue.

Kuniyuki I am releasing the syzbot bug with a repro, if you have time to fix NSH
all your patches can go away I think.

Re: [PATCH v1 net 1/5] sit: Pull header after checking skb->protocol in sit_tunnel_xmit().

[Paolo Abeni]

On Thu, 2024-04-18 at 09:00 +0200, Eric Dumazet wrote:
> On Thu, Apr 18, 2024 at 8:56 AM Eric Dumazet <edumazet@google.com> wrote:
> > 
> > On Thu, Apr 18, 2024 at 5:32 AM Kuniyuki Iwashima <kuniyu@amazon.com> wrote:
> > > 
> > > From: Jakub Kicinski <kuba@kernel.org>
> > > Date: Wed, 17 Apr 2024 19:04:32 -0700
> > > > On Mon, 15 Apr 2024 15:20:37 -0700 Kuniyuki Iwashima wrote:
> > > > > syzkaller crafted a GSO packet of ETH_P_8021AD + ETH_P_NSH and sent it
> > > > > over sit0.
> > > > > 
> > > > > After nsh_gso_segment(), skb->data - skb->head was 138, on the other
> > > > > hand, skb->network_header was 128.
> > > > 
> > > > is data offset > skb->network_header valid at this stage?
> > > > Can't we drop these packets instead?
> > > 
> > > I think that needs another fix on the NSH side.
> > > 
> > > But even with that, we can still pass valid L2 skb to sit_tunnel_xmit()
> > > and friends, and then we should just drop it there without calling
> > > pskb_inet_may_pull() that should not be called for non-IP skb.
> > 
> > I dislike this patch series. I had this NSH bug for a while in my
> > queue, the bug is in NSH.
> > 
> > Also I added skb_vlan_inet_prepare() recently for a similar issue.
> 
> Kuniyuki I am releasing the syzbot bug with a repro, if you have time to fix NSH
> all your patches can go away I think.

I agree a specific/smaller scope fix on in nsh should be preferred
here.

Thanks,

Paolo

Re: [PATCH v1 net 1/5] sit: Pull header after checking skb->protocol in sit_tunnel_xmit().

[Kuniyuki Iwashima]

From: Paolo Abeni <pabeni@redhat.com>
> On Thu, 2024-04-18 at 09:00 +0200, Eric Dumazet wrote:
> > On Thu, Apr 18, 2024 at 8:56 AM Eric Dumazet <edumazet@google.com> wrote:
> > > 
> > > On Thu, Apr 18, 2024 at 5:32 AM Kuniyuki Iwashima <kuniyu@amazon.com> wrote:
> > > > 
> > > > From: Jakub Kicinski <kuba@kernel.org>
> > > > Date: Wed, 17 Apr 2024 19:04:32 -0700
> > > > > On Mon, 15 Apr 2024 15:20:37 -0700 Kuniyuki Iwashima wrote:
> > > > > > syzkaller crafted a GSO packet of ETH_P_8021AD + ETH_P_NSH and sent it
> > > > > > over sit0.
> > > > > > 
> > > > > > After nsh_gso_segment(), skb->data - skb->head was 138, on the other
> > > > > > hand, skb->network_header was 128.
> > > > > 
> > > > > is data offset > skb->network_header valid at this stage?
> > > > > Can't we drop these packets instead?
> > > > 
> > > > I think that needs another fix on the NSH side.
> > > > 
> > > > But even with that, we can still pass valid L2 skb to sit_tunnel_xmit()
> > > > and friends, and then we should just drop it there without calling
> > > > pskb_inet_may_pull() that should not be called for non-IP skb.
> > > 
> > > I dislike this patch series. I had this NSH bug for a while in my
> > > queue, the bug is in NSH.
> > > 
> > > Also I added skb_vlan_inet_prepare() recently for a similar issue.
> > 
> > Kuniyuki I am releasing the syzbot bug with a repro, if you have time to fix NSH
> > all your patches can go away I think.

Thanks for sharing the repro, Eric!

> 
> I agree a specific/smaller scope fix on in nsh should be preferred

Hmm.. I think the bug is both in NSH and the tunnel xmit
functions in this series.

geneve is in a bit differnt position because L2 skb is sane
for geneve, and it needs to inspect vlan and the upper layer.

However, L3 tunnels should validate skb->protocol first before
accessing skb->network_header, otherwise that could trigger KMSAN.