From nobody Sun Feb 8 11:06:55 2026 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.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 6E0173382C6 for ; Mon, 19 Jan 2026 07:55:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768809330; cv=none; b=U9GVMjwYjHAQ7DOd+nzEjrmrtOcslog5f8moVGVrDQQHfuQhTxx4/iT9dCsQl8BN31v68kNhpB2gkjkH2/vN+pWq5NLTTPJ+hfh2nAesRAaArkIQvIv2cOIAP1l7iurSV73S9H8nfOnps4FLwQBFOB/bGoFGTTTr3wIHaMW0aLk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768809330; c=relaxed/simple; bh=D3BIbdokThuqChGIJiAOyjtWlnSmJF0CybBLz8VDIaQ=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=WAbuGvIIJbr98sshY/pzerquBPVon3J0hVD+HzeulmeTs8q4s2lvaVtQ7uA6pC+RTQ9ddzqanKNwbcykNu2qedzczEY5vqiMImQKSUO6ZEerQLLz5zOhnJkYHGSyrBUadug2NGAzkZpZx5UKOgiwMGTlrymBEa+miq7hQNrH+Ko= 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=W3m9jW0v; arc=none smtp.client-ip=170.10.133.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="W3m9jW0v" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1768809327; 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=NReIhTTUCZSSWOSG7kLsOU9Hbcxq2RDCscu9pS+Jra8=; b=W3m9jW0v6b8FXb06blpjKPZz3AaQ34NZu20YU72l3PAQO4v++lsxHO9RRn33o/a8jesOWH GggkEEAkyiqhWSdBp1vF1d6+CcNhYn0gMbhVsnweh5uCton9vHykTeViHsc8zkdz4JSuGB NRKia5OtUdBWvP/IUilNV1NsjL9wrGg= Received: from mx-prod-mc-08.mail-002.prod.us-west-2.aws.redhat.com (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-328-lIZVW_0EMgqarlCQmQtC9w-1; Mon, 19 Jan 2026 02:55:23 -0500 X-MC-Unique: lIZVW_0EMgqarlCQmQtC9w-1 X-Mimecast-MFC-AGG-ID: lIZVW_0EMgqarlCQmQtC9w_1768809322 Received: from mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.4]) (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-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 699CB180044D; Mon, 19 Jan 2026 07:55:22 +0000 (UTC) Received: from lenovo-t14s.redhat.com (unknown [10.45.224.165]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 1889430001A7; Mon, 19 Jan 2026 07:55:19 +0000 (UTC) From: Laurent Vivier To: linux-kernel@vger.kernel.org Cc: linux-usb@vger.kernel.org, Oliver Neukum , Jakub Kicinski , netdev@vger.kernel.org, Laurent Vivier , Stefano Brivio Subject: [PATCH net v2] usbnet: limit max_mtu based on device's hard_mtu Date: Mon, 19 Jan 2026 08:55:18 +0100 Message-ID: <20260119075518.2774373-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.4 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 Fixes: f77f0aee4da4 ("net: use core MTU range checking in USB NIC drivers") Signed-off-by: Laurent Vivier Link: https://bugs.passt.top/show_bug.cgi?id=3D189 Reviewed-by: Stefano Brivio --- drivers/net/usb/usbnet.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c index 36742e64cff7..1093c2a412d9 100644 --- a/drivers/net/usb/usbnet.c +++ b/drivers/net/usb/usbnet.c @@ -1821,9 +1821,12 @@ 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; + if (net->max_mtu > (dev->hard_mtu - net->hard_header_len)) + net->max_mtu =3D dev->hard_mtu - net->hard_header_len; + + 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