[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
>