| Message ID | 20240415222041.18537-2-kuniyu@amazon.com (mailing list archive) |
|---|---|
| State | Changes Requested |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | ip: Fix warning in pskb_may_pull_reason() for tunnel devices. | expand |
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?
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.
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.
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.
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
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.
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)
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(-)