qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC PATCH-for-5.2 1/2] net: Do not accept packets bigger then NET_B


From: Philippe Mathieu-Daudé
Subject: Re: [RFC PATCH-for-5.2 1/2] net: Do not accept packets bigger then NET_BUFSIZE
Date: Fri, 4 Dec 2020 15:01:04 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0

On 12/4/20 11:03 AM, P J P wrote:
> +-- On Fri, 27 Nov 2020, Philippe Mathieu-Daudé wrote --+
> | Do not allow qemu_send_packet*() and qemu_net_queue_send()
> | functions to accept packets bigger then NET_BUFSIZE.
> | 
> | We have to put a limit somewhere. NET_BUFSIZE is defined as:
> |  /* Maximum GSO packet size (64k) plus plenty of room for
> |   * the ethernet and virtio_net headers
> |   */
> |  #define NET_BUFSIZE (4096 + 65536)
> | 
> | +    if (size > NET_BUFSIZE) {
> | +        return -1;
> | +    }
> | +
> 
> /usr/include/linux/if_ether.h
>   #define ETH_MIN_MTU 68        /* Min IPv4 MTU per RFC791  */                
>       
>   #define ETH_MAX_MTU 0xFFFFU   /* 65535, same as IP_MAX_MTU    */
> 
>   if (size < ETH_MIN_MTU || size > ETH_MAX_MTU) {
>       return -1;
>   }
> 
> Should there be similar check for minimum packet size?

I don't think so, because this API is not restricted to Ethernet
frames (i.e. CAN frames are much shorter).
We also want developers be able to experiment with new protocols.

I'd rather not relate this with any protocol. Using an upper limit
doesn't hurt. Maybe not accepting frames bigger than 1 GiB is enough
from a security point of view.

> 
> Thank you.
> --
> Prasad J Pandit / Red Hat Product Security Team
> 8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]