netdev - RE: [PATCH net-next 1/2] virtio_net: Fix short frame length check

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: <PH0PR12MB5481299265978E6719F92A76DCC39@PH0PR12MB5481.namprd12.prod.outlook.com>
Date:   Sat, 14 Jan 2023 17:44:42 +0000
From:   Parav Pandit <parav@...dia.com>
To:     Alexander Duyck <alexander.duyck@...il.com>
CC:     "mst@...hat.com" <mst@...hat.com>,
        "jasowang@...hat.com" <jasowang@...hat.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "kuba@...nel.org" <kuba@...nel.org>,
        "edumazet@...gle.com" <edumazet@...gle.com>,
        "pabeni@...hat.com" <pabeni@...hat.com>,
        "virtualization@...ts.linux-foundation.org" 
        <virtualization@...ts.linux-foundation.org>
Subject: RE: [PATCH net-next 1/2] virtio_net: Fix short frame length check


> From: Alexander Duyck <alexander.duyck@...il.com>
> Sent: Friday, January 13, 2023 7:24 PM
> 
> On Fri, Jan 13, 2023 at 3:37 PM Parav Pandit <parav@...dia.com> wrote:
> >
> >
> > > From: Alexander H Duyck <alexander.duyck@...il.com>
> > > Sent: Friday, January 13, 2023 6:24 PM
> > >
> > > On Sat, 2023-01-14 at 00:36 +0200, Parav Pandit wrote:
> > > > A smallest Ethernet frame defined by IEEE 802.3 is 60 bytes
> > > > without any preemble and CRC.
> > > >
> > > > Current code only checks for minimal 14 bytes of Ethernet header length.
> > > > Correct it to consider the minimum Ethernet frame length.
> > > >
> > > > Fixes: 296f96fcfc16 ("Net driver using virtio")
> > > > Signed-off-by: Parav Pandit <parav@...dia.com>
> > > > ---
> > > >  drivers/net/virtio_net.c | 2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> > > > index
> > > > 7723b2a49d8e..d45e140b6852 100644
> > > > --- a/drivers/net/virtio_net.c
> > > > +++ b/drivers/net/virtio_net.c
> > > > @@ -1248,7 +1248,7 @@ static void receive_buf(struct virtnet_info
> > > > *vi,
> > > struct receive_queue *rq,
> > > >     struct sk_buff *skb;
> > > >     struct virtio_net_hdr_mrg_rxbuf *hdr;
> > > >
> > > > -   if (unlikely(len < vi->hdr_len + ETH_HLEN)) {
> > > > +   if (unlikely(len < vi->hdr_len + ETH_ZLEN)) {
> > > >             pr_debug("%s: short packet %i\n", dev->name, len);
> > > >             dev->stats.rx_length_errors++;
> > > >             if (vi->mergeable_rx_bufs) {
> > >
> > > I'm not sure I agree with this change as packets are only 60B if
> > > they have gone across the wire as they are usually padded out on the
> > > transmit side. There may be cases where software routed packets may not
> be 60B.
> > >
> > Do you mean Linux kernel software? Any link to it would be helpful.
> 
> The problem is there are several software paths involved and that is why I am
> wanting to be cautious. As I recall this would impact Qemu itself, DPDK, the
> Linux Kernel and several others if I am not mistaken. That is why I am tending to
> err on the side of caution as this is a pretty significant change.
> 
> > > As such rather than changing out ETH_HLEN for ETH_ZLEN I wonder if
> > > we should look at maybe making this a "<=" comparison instead since
> > > that is the only case I can think of where the packet would end up
> > > being entirely empty after eth_type_trans is called and we would be passing
> an skb with length 0.
> >
> > I likely didn’t understand your comment.
> > This driver check is before creating the skb for the received packet.
> > So, purpose is to not even process the packet header or prepare the skb if it
> not an Ethernet frame.
> >
> > It is interesting to know when we get < 60B frame.
> 
> If I recall, a UDPv4 frame can easily do it since Ethernet is 14B, IP header is 20,
> and UDP is only 8 so that only comes to 42B if I recall correctly. Similarly I think
> a TCPv4 Frame can be as small as 54B if you disable all the option headers.

Yes for sure < 60B Ethernet payload is very common which is usually padded by the nic tx.
I am familiar with it. :)

I missed the part that when virtio is sw emulated, the tx short frame(not padded by stack) never left the sw stack.
(never sent to the hw nic).
Hence, it was never padded, and it was looped back.
This will reach as short frame to virtio driver.

So yes, this patch breaks it. I will drop this patch.
Thanks Alexander for the catch.