netdev - Re: [PATCH net] net: do not allow gso_size to be set to GSO_BY

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANn89iLNH2_kL8SeAdr84Am9nW4tgk0XQC37mEWkaCf8n6hf7w@mail.gmail.com>
Date: Thu, 17 Aug 2023 08:17:55 +0200
From: Eric Dumazet <edumazet@...gle.com>
To: Xuan Zhuo <xuanzhuo@...ux.alibaba.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, 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.