Re: [PATCH] net: check the return value of the copy_from_sockptr

From: Eric Dumazet
Date: Wed Sep 11 2024 - 13:16:01 EST


On Wed, Sep 11, 2024 at 6:58 PM Cong Wang <xiyou.wangcong@xxxxxxxxx> wrote:
>
> On Wed, Sep 11, 2024 at 11:12:24AM +0200, Eric Dumazet wrote:
> > On Wed, Sep 11, 2024 at 10:23 AM Qianqiang Liu <qianqiang.liu@xxxxxxx> wrote:
> > >
> > > > I do not think it matters, because the copy is performed later, with
> > > > all the needed checks.
> > >
> > > No, there is no checks at all.
> > >
> >
> > Please elaborate ?
> > Why should maintainers have to spend time to provide evidence to
> > support your claims ?
> > Have you thought about the (compat) case ?
> >
> > There are plenty of checks. They were there before Stanislav commit.
> >
> > Each getsockopt() handler must perform the same actions.
>
>
> But in line 2379 we have ops->getsockopt==NULL case:
>
> 2373 if (!compat)
> 2374 copy_from_sockptr(&max_optlen, optlen, sizeof(int));
> 2375
> 2376 ops = READ_ONCE(sock->ops);
> 2377 if (level == SOL_SOCKET) {
> 2378 err = sk_getsockopt(sock->sk, level, optname, optval, optlen);
> 2379 } else if (unlikely(!ops->getsockopt)) {
> 2380 err = -EOPNOTSUPP; // <--- HERE
> 2381 } else {
> 2382 if (WARN_ONCE(optval.is_kernel || optlen.is_kernel,
> 2383 "Invalid argument type"))
> 2384 return -EOPNOTSUPP;
> 2385
> 2386 err = ops->getsockopt(sock, level, optname, optval.user,
> 2387 optlen.user);
> 2388 }
>
> where we simply continue with calling BPF_CGROUP_RUN_PROG_GETSOCKOPT()
> which actually needs the 'max_optlen' we copied via copy_from_sockptr().
>
> Do I miss anything here?

This is another great reason why we should not change current behavior.

err will be -EOPNOTSUPP, which was the original error code before
Stanislav patch.

Surely the eBPF program will use this value first, and not even look
at max_optlen

Returning -EFAULT might break some user programs, I don't know.

I feel we are making the kernel slower just because we can.