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: <92b98f45dcd65facac78133c6250d9d96ea1a25f.camel@gmail.com>
Date:   Fri, 13 Jan 2023 15:24:15 -0800
From:   Alexander H Duyck <alexander.duyck@...il.com>
To:     Parav Pandit <parav@...dia.com>, mst@...hat.com,
        jasowang@...hat.com, netdev@...r.kernel.org, davem@...emloft.net,
        kuba@...nel.org
Cc:     edumazet@...gle.com, pabeni@...hat.com,
        virtualization@...ts.linux-foundation.org
Subject: Re: [PATCH net-next 1/2] virtio_net: Fix short frame length check

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.

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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ