Message-ID: <1692254912.6879-1-xuanzhuo@linux.alibaba.com>
Date: Thu, 17 Aug 2023 14:48:32 +0800
From: Xuan Zhuo <xuanzhuo@...ux.alibaba.com>
To: Eric Dumazet <edumazet@...gle.com>
Cc: netdev@...r.kernel.org,
 eric.dumazet@...il.com,
 syzbot <syzkaller@...glegroups.com>,
 Xin Long <lucien.xin@...il.com>,
 Marcelo Ricardo Leitner <marcelo.leitner@...il.com>,
 Willem de Bruijn <willemb@...gle.com>,
 "Michael S. Tsirkin" <mst@...hat.com>,
 Jason Wang <jasowang@...hat.com>,
 "David S . Miller" <davem@...emloft.net>,
 Jakub Kicinski <kuba@...nel.org>,
 Paolo Abeni <pabeni@...hat.com>
Subject: Re: [PATCH net] net: do not allow gso_size to be set to GSO_BY_FRAGS

On Thu, 17 Aug 2023 08:17:55 +0200, Eric Dumazet <edumazet@...gle.com> wrote:
> On Thu, Aug 17, 2023 at 4:27 AM Xuan Zhuo <xuanzhuo@...ux.alibaba.com> wrote:
> >
> > On Wed, 16 Aug 2023 14:21:58 +0000, Eric Dumazet <edumazet@...gle.com> wrote:
> > > One missing check in virtio_net_hdr_to_skb() allowed
> > > syzbot to crash kernels again [1]
> > >
> > > Do not allow gso_size to be set to GSO_BY_FRAGS (0xffff),
> > > because this magic value is used by the kernel.
> > >
> > > [1]
> > > general protection fault, probably for non-canonical address 0xdffffc000000000e: 0000 [#1] PREEMPT SMP KASAN
> > > KASAN: null-ptr-deref in range [0x0000000000000070-0x0000000000000077]
> > > CPU: 0 PID: 5039 Comm: syz-executor401 Not tainted 6.5.0-rc5-next-20230809-syzkaller #0
> > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/26/2023
> > > RIP: 0010:skb_segment+0x1a52/0x3ef0 net/core/skbuff.c:4500
> > > Code: 00 00 00 e9 ab eb ff ff e8 6b 96 5d f9 48 8b 84 24 00 01 00 00 48 8d 78 70 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 08 3c 03 0f 8e ea 21 00 00 48 8b 84 24 00 01
> > > RSP: 0018:ffffc90003d3f1c8 EFLAGS: 00010202
> > > RAX: dffffc0000000000 RBX: 000000000001fffe RCX: 0000000000000000
> > > RDX: 000000000000000e RSI: ffffffff882a3115 RDI: 0000000000000070
> > > RBP: ffffc90003d3f378 R08: 0000000000000005 R09: 000000000000ffff
> > > R10: 000000000000ffff R11: 5ee4a93e456187d6 R12: 000000000001ffc6
> > > R13: dffffc0000000000 R14: 0000000000000008 R15: 000000000000ffff
> > > FS: 00005555563f2380(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000
> > > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > > CR2: 0000000020020000 CR3: 000000001626d000 CR4: 00000000003506f0
> > > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> > > DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> > > Call Trace:
> > > <TASK>
> > > udp6_ufo_fragment+0x9d2/0xd50 net/ipv6/udp_offload.c:109
> > > ipv6_gso_segment+0x5c4/0x17b0 net/ipv6/ip6_offload.c:120
> > > skb_mac_gso_segment+0x292/0x610 net/core/gso.c:53
> > > __skb_gso_segment+0x339/0x710 net/core/gso.c:124
> > > skb_gso_segment include/net/gso.h:83 [inline]
> > > validate_xmit_skb+0x3a5/0xf10 net/core/dev.c:3625
> > > __dev_queue_xmit+0x8f0/0x3d60 net/core/dev.c:4329
> > > dev_queue_xmit include/linux/netdevice.h:3082 [inline]
> > > packet_xmit+0x257/0x380 net/packet/af_packet.c:276
> > > packet_snd net/packet/af_packet.c:3087 [inline]
> > > packet_sendmsg+0x24c7/0x5570 net/packet/af_packet.c:3119
> > > sock_sendmsg_nosec net/socket.c:727 [inline]
> > > sock_sendmsg+0xd9/0x180 net/socket.c:750
> > > ____sys_sendmsg+0x6ac/0x940 net/socket.c:2496
> > > ___sys_sendmsg+0x135/0x1d0 net/socket.c:2550
> > > __sys_sendmsg+0x117/0x1e0 net/socket.c:2579
> > > do_syscall_x64 arch/x86/entry/common.c:50 [inline]
> > > do_syscall_64+0x38/0xb0 arch/x86/entry/common.c:80
> > > entry_SYSCALL_64_after_hwframe+0x63/0xcd
> > > RIP: 0033:0x7ff27cdb34d9
> > >
> > > Fixes: 3953c46c3ac7 ("sk_buff: allow segmenting based on frag sizes")
> > > Reported-by: syzbot <syzkaller@...glegroups.com>
> > > Signed-off-by: Eric Dumazet <edumazet@...gle.com>
> > > Cc: Xin Long <lucien.xin@...il.com>
> > > Cc: Marcelo Ricardo Leitner <marcelo.leitner@...il.com>
> > > Cc: Willem de Bruijn <willemb@...gle.com>
> > > Cc: "Michael S. Tsirkin" <mst@...hat.com>
> > > Cc: Jason Wang <jasowang@...hat.com>
> > > Cc: Xuan Zhuo <xuanzhuo@...ux.alibaba.com>
> > > ---
> > >  include/linux/virtio_net.h | 4 ++++
> > >  1 file changed, 4 insertions(+)
> > >
> > > diff --git a/include/linux/virtio_net.h b/include/linux/virtio_net.h
> > > index bdf8de2cdd935d31449b78e1b9c67fdcdc537bf2..7b4dd69555e497497460dcf5d72737fe5c09fd53 100644
> > > --- a/include/linux/virtio_net.h
> > > +++ b/include/linux/virtio_net.h
> > > @@ -155,6 +155,10 @@ static inline int virtio_net_hdr_to_skb(struct sk_buff *skb,
> > >               if (gso_type & SKB_GSO_UDP)
> > >                       nh_off -= thlen;
> > >
> > > +             /* Kernel has a special handling for GSO_BY_FRAGS. */
> > > +             if (gso_size == GSO_BY_FRAGS)
> > > +                     return -EINVAL;
> > > +
> >
> >
> > I guess the crash happens when user sends packets via af_packet and gso is set
> > to GSO_BY_FRAGS by user.
> >
> > But I wonder is 0xffff also an invalid value on the rx path?
> >
> > We know that this function virtio_net_hdr_to_skb is also used by the virtio-net
> > driver on the rx path. This change means that virtio-net devices should not set
> > gso to 0xffff. But the virtio spec doesn't say that the rx gso value 0xffff is
> > invalid.
> >
> > So I think we should not add check in this function.
>
>
> I think we do.
>
> Think about it, how gso_size == 0xffff , or even 0xfff0 could be valid ?
>
> We are not going to add more core in core network fast path, for
> something that can not happen with kernel stacks.
>
> It is time someone clarifies virtio_specs, because 0xffff is
> absolutely a no go, even before blamed commit.


So do you mean there are some limitations for the max value of gso_size?

But the merge mode of the virtio-net can receive big packets.

So what is the limitations?

Thanks.

Powered by blists - more mailing lists