Re: [PATCH net-next v3 0/4] net: move .getsockopt away from __user buffers

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 [off-list ref] wrote:

quoted

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?

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