From nobody Sun Feb 8 17:41:42 2026 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E48E532D0F0 for ; Wed, 14 Jan 2026 09:03:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768381411; cv=none; b=iNkRBM9RjeJUf3Xouz3vR1x5JPGEW4lfr95AEpi0dk+kP0ODnJOw5kdh9KHfvzq2r8G3MH7eqaTyrZWBUur2l6GxmXvqtZA1fqqd1fMYTvXdvv3dM7MbRmEbbgim7pSMiWIDY3Sw6HOMZ7vhOrl8u1ftgvSsfM70XdR/zqyhEvs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768381411; c=relaxed/simple; bh=mU6ejUGlwUAibc9npSixGfRqp5mvk3uT2gxe6YRqu2Q=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=EMdMKnN12CXmSD1pjl6hkjYsJ8J9GspLGHRJ+94ZjQlak5mhKvbGN7zVQac5tPT5Z9i+QHBgQ1oKyfUCZN3u6vot7qiXgdkiTM9hnEnXzVhAzninYuQuY+2y8qh6ROvHGZ2qjtz9vCrgN/SYWjX1yBVtdK/1fKITQkqWrkns6Ug= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=fNacqMY1; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="fNacqMY1" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1768381406; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=5Ohio87n6rJ1fHkc1Q0/QDujSz+L4naGbi/eaeFTmR0=; b=fNacqMY1FzMpBhofOk9g9YGw8zcC0eS+0+8yrLkvs7uW8wuw7oId/AFUdYLHEq+cefN1oe Yn/IqfysKBWTXDE2UbgFCX4F5vM1CplOFNSEu0+VTKolAymiAzMs9mZkMRYj20r95Zrwm8 f6s2Rurt1//17arhEYzu0ls+V+PYuYQ= Received: from mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-689-XTQSlR3qNzSKVAEQByTgxw-1; Wed, 14 Jan 2026 04:03:23 -0500 X-MC-Unique: XTQSlR3qNzSKVAEQByTgxw-1 X-Mimecast-MFC-AGG-ID: XTQSlR3qNzSKVAEQByTgxw_1768381402 Received: from mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.93]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 6E01B195605F; Wed, 14 Jan 2026 09:03:22 +0000 (UTC) Received: from lenovo-t14s.redhat.com (unknown [10.44.32.149]) by mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 2066D1800665; Wed, 14 Jan 2026 09:03:19 +0000 (UTC) From: Laurent Vivier To: linux-kernel@vger.kernel.org Cc: netdev@vger.kernel.org, Oliver Neukum , linux-usb@vger.kernel.org, Laurent Vivier Subject: [PATCH] usbnet: limit max_mtu based on device's hard_mtu Date: Wed, 14 Jan 2026 10:03:17 +0100 Message-ID: <20260114090317.3214026-1-lvivier@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.93 Content-Type: text/plain; charset="utf-8" The usbnet driver initializes net->max_mtu to ETH_MAX_MTU before calling the device's bind() callback. When the bind() callback sets dev->hard_mtu based the device's actual capability (from CDC Ethernet's wMaxSegmentSize descriptor), max_mtu is never updated to reflect this hardware limitation). This allows userspace (DHCP or IPv6 RA) to configure MTU larger than the device can handle, leading to silent packet drops when the backend sends packet exceeding the device's buffer size. Fix this by limiting net->max_mtu to the device's hard_mtu after the bind callback returns. See https://gitlab.com/qemu-project/qemu/-/issues/3268 and https://bugs.passt.top/attachment.cgi?bugid=3D189 Signed-off-by: Laurent Vivier Reviewed-by: Stefano Brivio --- drivers/net/usb/usbnet.c | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c index 36742e64cff7..8dbbeb8ce3f8 100644 --- a/drivers/net/usb/usbnet.c +++ b/drivers/net/usb/usbnet.c @@ -1821,9 +1821,14 @@ usbnet_probe(struct usb_interface *udev, const struc= t usb_device_id *prod) if ((dev->driver_info->flags & FLAG_NOARP) !=3D 0) net->flags |=3D IFF_NOARP; =20 - /* maybe the remote can't receive an Ethernet MTU */ - if (net->mtu > (dev->hard_mtu - net->hard_header_len)) - net->mtu =3D dev->hard_mtu - net->hard_header_len; + /* limit max_mtu to the device's hard_mtu */ + if (net->max_mtu > (dev->hard_mtu - net->hard_header_len)) + net->max_mtu =3D dev->hard_mtu - net->hard_header_len; + + /* limit mtu to max_mtu */ + if (net->mtu > net->max_mtu) + net->mtu =3D net->max_mtu; + } else if (!info->in || !info->out) status =3D usbnet_get_endpoints(dev, udev); else { --=20 2.52.0