From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-oi1-f193.google.com (mail-oi1-f193.google.com [209.85.167.193]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 99A093DCDAA for ; Thu, 9 Apr 2026 15:37:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.167.193 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775749030; cv=none; b=IAnUH1eWlCVt4PQ1mK3QuGeP8HcFQbvhD8U7hpdQeVK6jw5P6j5McVo6ACV7BX4huljokYP4fjHHMhk+dVU0IL8uJko9XbFj0TZEMxu4fBKulupixrFP2w7nGCSVXX8de5WhEIj4KBADApMrbX8Rr0VDhgxbgLT+TDPSc0D5Yt8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775749030; c=relaxed/simple; bh=QdbJoop8F6WUCHtK2jKo8EiZNDeMxXFVpx1o53KKEsM=; h=From:Date:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=TADXLdBhdobm5le3lXmDCrv9rfVUWCEPTVmxKJ2MgiHYFlAoxyb4tpFN8V68h+zXU/SqEprkKq8wYhf7LjtuXHTeQPYkr41/1JJ6MAfqzZcjfIwKTPVkgiPZRMHxkzIDMy8NjD3Gnfzhug5FNX88T1Yl9ddPZRpZw26cOofg01g= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=VPDQJn9z; arc=none smtp.client-ip=209.85.167.193 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="VPDQJn9z" Received: by mail-oi1-f193.google.com with SMTP id 5614622812f47-45f053b7b90so562240b6e.0 for ; Thu, 09 Apr 2026 08:37:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1775749028; x=1776353828; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:date:from:from:to:cc:subject:date:message-id:reply-to; bh=RoUvb32JF6evSc4jt8i6LUGICotsiB1SCO2ERGQh4Ig=; b=VPDQJn9zVsgHUpY33xROmCCF4GW4lrnFtpu1mTEdPjy8iWigJhWbf0YwbrD5pjdpfH t85zSjmuqHN71kKQzjLsMRnfqH9ryIwrjzlLd2WRBIKh/mq555ZU0zLlVfGldHCNKfuv K1fcXBF9z/rYgg4EHw2SEUqEJhnEHSEpXz8yxmPBgL1Ujg1GPMIJRLT5HsWZ1xTKjzIu t3CgAN7YqTAfVV+C/6sRXSpFHWCmEN7mmOs8PafJwoKOgjBD19GI36QFwF4BU4AQoVI+ 2J/ptGqRSj5NjkzupVdP1vdbnG5DwX7FiDx/tIhiE2a/lT6ZE6GKL9bpAmB4nZmY8xOI 7qrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775749028; x=1776353828; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:date:from:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=RoUvb32JF6evSc4jt8i6LUGICotsiB1SCO2ERGQh4Ig=; b=KysYmvVTZ8sa8aVQLQCAHwq6ENSPQBdwNt7/IpGXOUv1i8oh6VlIdvVFyift1ozbsQ SkIsOn5JjNdTl3/UAQ2iMnLGpIdgY+E9ZYIKQdwYFGgOdgE0TZQdG1sdYP0huM6ybfhK /h2rzlBXx3SJIZx5CkZPcrm2hhAXQQNgA8wvVcSW6z/RufyxS7Ar37TN/PQIuqkB4Qzu mnfGGyij4zARmeug1aFTxKdSIYdwqeOytZF99s0yapNTw1GVyhm0qObcT4uxcx/3DL1k XTGKRd9M00FEnHgTUa12gj9B6QNwRcne4WYzZvATd6R+PKqch5DFfafVU5qUjb18zGrt wjXA== X-Forwarded-Encrypted: i=1; AJvYcCUef1At+C8H9liVSRFAivLuQSXmye49hWspTuNoX/XjfMzNLmXcKVl9n8tfBpFEjArk53iiXnnLwUGSgss=@vger.kernel.org X-Gm-Message-State: AOJu0Yw7sT5PBezAqXlm3FPuLSKI10TsmYHuMtW3+YMNiihHXJ7pxpMa ocbMKo2RTak52v8h6kSVxMdzk+QP8XkuGfb2nCG5VruULEqeZofgLfar X-Gm-Gg: AeBDieurk89i9jINWBSY6p7SGqvaVcFUfD9UvjzJuP+/xN3b1vzmx67Ba5xIRlOQRGU 2tU0ohnkPLuu67svHHU/aIZ9sMqQ315R8v5SCeOX8+fc3JZbOK8svmfYE3tbdYbOOZSqKUozKy8 AuQd4McgKH+5aV33Ks8/wkXA6qUOimRQzrY+mvLvWZv53LlCu1CnUgB/qfhqtG8/wLm5q4radhh /Q1jnSiAiSxFM97mwzdRr7LasPjAksxg9D/OMlCnq8CdevBvulUeK+sIMUlmJuSRiNnpkYddxvT qOtxcC3+tdPabqwgqcC1QiDsMwVggeoxPkfY0IRrK8p6kNm0aPuhsAYmCucriAAFK+/+nEKhRa3 vAwfNKZKRHdL5MrHk8iLCXdqM+ONXyk2qtrD/nsQAXXGjv6/QGt2p7QDycesMmkyQLUOgkAQUHA WYiIYHLJGs1bcDpzoPiw== X-Received: by 2002:a05:6808:1513:b0:467:1462:a9b3 with SMTP id 5614622812f47-46ef8217b05mr13237077b6e.38.1775749028389; Thu, 09 Apr 2026 08:37:08 -0700 (PDT) Received: from localhost ([2a03:2880:12ff:44::]) by smtp.gmail.com with ESMTPSA id 46e09a7af769-7dc2660ef75sm59468a34.10.2026.04.09.08.37.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 09 Apr 2026 08:37:07 -0700 (PDT) From: Stanislav Fomichev X-Google-Original-From: Stanislav Fomichev Date: Thu, 9 Apr 2026 08:37:07 -0700 To: Jakub Kicinski Cc: Stanislav Fomichev , Hangbin Liu , Donald Hunter , "David S. Miller" , Eric Dumazet , Paolo Abeni , Simon Horman , Andrew Lunn , netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH net-next v2 5/5] ethtool: strset: check nla_len overflow Message-ID: References: <20260408-b4-ynl_ethtool-v2-0-7623a5e8f70b@gmail.com> <20260408-b4-ynl_ethtool-v2-5-7623a5e8f70b@gmail.com> <20260408173943.2c239ae8@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20260408173943.2c239ae8@kernel.org> On 04/08, Jakub Kicinski wrote: > On Wed, 8 Apr 2026 09:43:35 -0700 Stanislav Fomichev wrote: > > On 04/08, Hangbin Liu wrote: > > > The netlink attribute length field nla_len is a __u16, which can only > > > represent values up to 65535 bytes. NICs with a large number of > > > statistics strings (e.g. mlx5_core with thousands of ETH_SS_STATS > > > entries) can produce a ETHTOOL_A_STRINGSET_STRINGS nest that exceeds > > > this limit. > > > > > > When nla_nest_end() writes the actual nest size back to nla_len, the > > > value is silently truncated. This results in a corrupted netlink message > > > being sent to userspace: the parser reads a wrong (truncated) attribute > > > length and misaligns all subsequent attribute boundaries, causing decode > > > errors. > > > > > > Fix this by using the new helper nla_nest_end_safe and error out if > > > the size exceeds U16_MAX. > > > > Not sure that's the user supposed to do? Does it mean there is no way > > to retrieve ETHTOOL_A_STRINGSET_STRINGS for those devices with too > > many strings? > > Not via Netlink, they can still read them via the ioctl? > Since the legacy stats themselves can't be fetched over Netlink > I'm not sure we should lose sleep over reading the stats strings > via Netlink. I guess... Should we update ethtool.yaml doc to tell the users to prefer ioctl over netlink for strset-get and mention this new EMSGSIZE?