linux-kernel - Re: [PATCH] net: Fix for packets being rejected in the xHCI controller's ring buffer

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]

Date:   Tue, 13 Dec 2022 19:23:13 +0100
From:   Daniele Palmas <dnlplm@...il.com>
To:     "Seija K." <doremylover123@...il.com>
Cc:     Bjørn Mork <bjorn@...k.no>,
        "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>, netdev@...r.kernel.org,
        linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] net: Fix for packets being rejected in the xHCI
 controller's ring buffer

Hello Seija,

Il giorno mar 13 dic 2022 alle ore 18:44 Seija K.
<doremylover123@...il.com> ha scritto:
>
> When a packet larger than MTU arrives in Linux from the modem, it is
> discarded with -EOVERFLOW error (Babble error).
>
> This is seen on USB3.0 and USB2.0 buses.
>
> This is because the MRU (Max Receive Size) is not a separate entity
> from the MTU (Max Transmit Size), and the received packets can be
> larger than those transmitted.
>
> Following the babble error, there was an endless supply of zero-length
> URBs that were rejected with -EPROTO (increasing the rx input error
> counter each time).
>
> This is only seen on USB3.0. These continue to come ad infinitum until
> the modem is shut down.
>
> There appears to be a bug in the core USB handling code in Linux that
> doesn't deal with network MTUs smaller than 1500 bytes well.
>
> By default, the dev->hard_mtu (the real MTU) is in lockstep with
> dev->rx_urb_size (essentially an MRU), and the latter is causing
> trouble.
>
> This has nothing to do with the modems; the issue can be reproduced by
> getting a USB-Ethernet dongle, setting the MTU to 1430, and pinging
> with size greater than 1406.
>
> Signed-off-by: Seija Kijin <doremylover123@...il.com>
>
> Co-Authored-By: TarAldarion <gildeap@....ie>
> ---
> drivers/net/usb/qmi_wwan.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
> index 554d4e2a84a4..39db53a74b5a 100644
> --- a/drivers/net/usb/qmi_wwan.c
> +++ b/drivers/net/usb/qmi_wwan.c
> @@ -842,6 +842,13 @@ static int qmi_wwan_bind(struct usbnet *dev,
> struct usb_interface *intf)
> }
> dev->net->netdev_ops = &qmi_wwan_netdev_ops;
> dev->net->sysfs_groups[0] = &qmi_wwan_sysfs_attr_group;
> + /* LTE Networks don't always respect their own MTU on the receiving side;
> + * e.g. AT&T pushes 1430 MTU but still allows 1500 byte packets from
> + * far-end networks. Make the receive buffer large enough to accommodate
> + * them, and add four bytes so MTU does not equal MRU on network
> + * with 1500 MTU. Otherwise, usbnet_change_mtu() will change both.
> + */
> + dev->rx_urb_size = ETH_DATA_LEN + 4;

Did you test this change with QMAP?

To support qmap dl aggregated blocks qmi_wwan relies on the
usbnet_change_mtu behavior of changing the rx_urb_size.

Thanks,
Daniele

> err:
> return status;
> }
> --
> 2.38.2