From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f45.google.com (mail-wm1-f45.google.com [209.85.128.45]) (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 37AAD348453 for ; Wed, 8 Apr 2026 18:56:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.45 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775674607; cv=none; b=b+mJp78RJhV6VqsP2IWOubXl4d+TM9EFFuhyHSMAv8ZqC133wAgHN1jFXODt+Z0FMWJLVRSU4CVewTGsuBB4WpqJNdvtvVEv0vqNZxua0mSwHOrfRQlOmGylhHhAoK1L+SEezpYdjECprPGfZ/rdABbMHtOQ/0K9EoQXHPYl/EA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775674607; c=relaxed/simple; bh=crZm2PijcEAXzpKSJa5xA82z7xsDYnBu7ZN0nWLhBuQ=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=h192IhCcoZtJiaru9VmSS3p1L9qKb261YBPhL+nE2mwImo3LYPPD2tZmyT1XjI/EiYuD+l3I1ejsyPNBEE/3ixC+mRLPa1K5dvtHYnjFCLj0bwaOhonrl6EO9nuCr1fsqdkGQbZKDhR8cg1b/9Qxz7OsaHVXJut6SP6d7xRF8tA= 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=j/3pooMV; arc=none smtp.client-ip=209.85.128.45 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="j/3pooMV" Received: by mail-wm1-f45.google.com with SMTP id 5b1f17b1804b1-488a041eae5so421895e9.1 for ; Wed, 08 Apr 2026 11:56:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1775674602; x=1776279402; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=6SerQ/zT5jOcTdy+y8E9YY089fNttq9APZn3BZTXc58=; b=j/3pooMVrumXrMdNyTUFFQ2zdsP2Y8tQqosjKcKYNA7TzLaJ4DfPI5q/DpK5Bd8k6z CWt9T8JOdAsQ8jZfHTV9AC0ezqEMRjHfBlq08e6iezIgovNg6QkkdePK9y2LFh59ioZU KLe7K0P2jgoTQfKcMdtbvg2Jz7z1ISNO9B5VZFfsKpv0AewkU0EtMhvRejYfh5jB59X2 TvpqnRsfHv7Bfj13a6GFqOkh3Bqt5FZGrNvj1zLvOh7paRgIgXFm1UVkdqf0c6e9B1yq 4v0XBypuFMSrQsyv1xzGoJYrmeHeYTxykBXGIQwTkcGEX26VFxQsfZjwLe5IYnW91hls GXQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775674602; x=1776279402; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=6SerQ/zT5jOcTdy+y8E9YY089fNttq9APZn3BZTXc58=; b=sIcwuY3eWz2QNAkfswX/yLRRtfn/g/SWEWRnYoSbtQ5+gk+8c9XjscskiQQpaI7DO3 LAJHjKQS7eAAngbxwsma9j0mcTMbNptijr9k/6T7IOd5U48EuuXoG+GRYLWdY5yrTixV 5bIqQ3dF2uABQPiGnF3riI7dEytHro+qFcfBhxJQkbP2Qm04nEGvsJW+nX6ML3I/QYeC JTOO/lOnvYVqzL2TZDsOKdzmIFrzel6MsicedYnXQiUBxbHY9gzjbiPfhk/Eo6xHCO1q A0e5nambJxjO1ECfRAc9oi8UcDAt/eRPvwyXt0eWYv8C/hf3Um8L3/fiCSl/LPblrCRf aWRw== X-Forwarded-Encrypted: i=1; AJvYcCVqp9XGvXfpFQvSTlCt/MAVZFWl+agM1jFzjN9hJ2E2t6/sqXjFXRgbfqKjxaGvuuXclgifhEaR6/GoK9g=@vger.kernel.org X-Gm-Message-State: AOJu0Yz5XkZF8Ho/UGBYwwh8qT8k+icBJH8CplrwPrUbenP58z6mMAkb VX3Z5NWfyYD32DbAp6WQcJu/X29rMP7zNIV/m4QyTCtv8XZw3qhtWJFo X-Gm-Gg: AeBDiesELYiZoYcK1Q61uo3M5fIDJipse0wKJoINhtOHIs4ln9HSokwpYKO9kG/nze+ KqW3ewMlpeR48ljdlI9AVGA87uGN2LeSTxOp1aqj3TEsGahykJXoZYkkGGWvh0QA4YjxRIBbPDD rK+vUcjJfM52YNwx2FBQsjsG1oBx8jKK6P/ybvoqq1A3fmYesQEQxLFpm+2+2UG41PLvDA7dhbd oKD633PEgfFeAinAjoIg30v7zcTuOksPrsbnQX7kjovtqo1rF4CwYTYhYq5BKlFbed1zaVB5GYu 8l8e9VR02GMhJoLN44NpXyneH2z5WX/SA3vZwoZoCljd4U9DAA9GQqdfna0K4pSnmuD0K3yGl7J r8FlHzrtN1R8pAMFwR8DOxdDG8asJi2S2jfKIyOaM7AqPGbEnG2DqxJ/jl7JkGq8yYwtORhFQBQ tcoLzqfHkDDNsGCShhE8IIFwWilBIoxz6Yb74vwcpPPuDJdZS3/Y8mb0wopRsavNZK X-Received: by 2002:a05:600c:630a:b0:485:2fe9:336f with SMTP id 5b1f17b1804b1-488998e3cbemr314394195e9.30.1775674602340; Wed, 08 Apr 2026 11:56:42 -0700 (PDT) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43d1e4e221bsm57990166f8f.29.2026.04.08.11.56.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 08 Apr 2026 11:56:41 -0700 (PDT) Date: Wed, 8 Apr 2026 19:56:40 +0100 From: David Laight To: Breno Leitao Cc: "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Kuniyuki Iwashima , Willem de Bruijn , metze@samba.org, axboe@kernel.dk, Stanislav Fomichev , io-uring@vger.kernel.org, bpf@vger.kernel.org, netdev@vger.kernel.org, Linus Torvalds , linux-kernel@vger.kernel.org, kernel-team@meta.com Subject: Re: [PATCH net-next v3 0/4] net: move .getsockopt away from __user buffers Message-ID: <20260408195640.324ee932@pumpkin> In-Reply-To: References: <20260408-getsockopt-v3-0-061bb9cb355d@debian.org> <20260408122653.295953dd@pumpkin> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) 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=US-ASCII Content-Transfer-Encoding: 7bit On Wed, 8 Apr 2026 06:52:54 -0700 Breno Leitao wrote: > Hello David, > > On Wed, Apr 08, 2026 at 12:26:53PM +0100, David Laight wrote: > > On Wed, 08 Apr 2026 03:30:28 -0700 > > Breno Leitao wrote: > > > > > Currently, the .getsockopt callback requires __user pointers: > > > > > > int (*getsockopt)(struct socket *sock, int level, > > > int optname, char __user *optval, int __user *optlen); > > > > > > This prevents kernel callers (io_uring, BPF) from using getsockopt on > > > levels other than SOL_SOCKET, since they pass kernel pointers. > > > > > > Following Linus' suggestion [0], this series introduces sockopt_t, a > > > type-safe wrapper around iov_iter, and a getsockopt_iter callback that > > > works with both user and kernel buffers. AF_PACKET and CAN raw are > > > converted as initial users, with selftests covering the trickiest > > > conversion patterns. > > > > What are you doing about the cases where 'optlen' is a complete lie? > > Is this incorrect optlen originating from userspace, and getting into > the .getsockopt callbacks? Look at tcp_ao_copy_mptks_to_user() in net/ipv4/tcp_ao.c This isn't 'old code' it was added in 2023. Basically what is being transferred is an array and 'optlen' is the size of one element. The number of elements is in the first one. Yes, it is completely broken. There was also some very old code that just didn't check the length (probably only for 'int' sized parameters). That might all have disappeared when decnet support was removed. There was also a very longstanding bug that pretty much all the IP protocols would treat negative lengths as 4. That got 'fixed' not long ago, I do wonder how many applications that broke! Passing an uninitialised on-stack variable would have worked (for 'int' parameters) provided it wasn't in [0..3]. Even then there is code that will copy 1 byte (instead of 4) when a short length is passed - but it only does something sensible on LE. I've been though all this code trying to replace the 'int *optlen' with 'unsigned int optlen' and then returning the updated length (or -ERRNO) to the wrapper. That simplifies 99% of the code. However there are a very small number of places that want to return an error with a corrected length. If you were starting from scratch you could say that returning a bigger length would return a specific errno (maybe -ERANGE) and the updated length - but there is no consistency. I pretty much decided that the getsockopt() functions would have to be able to return one of: -errno length GETSOCKOPT_RVAL(errno, lenght) with the wrapper separating out the merged value. David > > > IIRC there is one related to some form of async io where it is just > > the length of the header, the actual buffer length depends on > > data in the header. > > Could you point me to the relevant code so I can examine this case? > > > This doesn't matter with the existing code for applications, when they > > get it wrong they just crash. > > Is this crash being triggered by the protocol callbacks? > > I tried searching for this but couldn't find it. I'd appreciate any > hints you could provide about this case. > > Thanks > --breno