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

From: Breno Leitao <[email-masked]>
Date: Wed, 8 Apr 2026 06:52:54 -0700

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 <[email-masked]> 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?

> 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