From: Stanislav Fomichev <stfomichev@gmail.com>
To: Cong Wang <xiyou.wangcong@gmail.com>
Cc: Eric Dumazet <edumazet@google.com>,
Qianqiang Liu <qianqiang.liu@163.com>,
davem@davemloft.net, kuba@kernel.org, pabeni@redhat.com,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] net: check the return value of the copy_from_sockptr
Date: Wed, 11 Sep 2024 13:05:27 -0700 [thread overview]
Message-ID: <ZuH4B7STmaY0AI1m@mini-arch> (raw)
In-Reply-To: <ZuHz9lSFY4dWD/4W@pop-os.localdomain>
On 09/11, Cong Wang wrote:
> On Wed, Sep 11, 2024 at 11:49:32AM -0700, Stanislav Fomichev wrote:
> > Can you explain what is not correct?
> >
> > Calling BPF_CGROUP_RUN_PROG_GETSOCKOPT with max_optlen=0 should not be
> > a problem I think? (the buffer simply won't be accessible to the bpf prog)
>
> Sure. Sorry for not providing all the details.
>
> If I understand the behavior of copy_from_user() correctly, it may
> return partially copied data in case of error, which then leads to a
> partially-copied 'max_optlen'.
>
> So, do you expect a partially-copied max_optlen to be passed to the
> eBPF program meanwhile the user still expects a complete one (since no
> -EFAULT)?
>
> Thanks.
Partial copy is basically the same as user giving us garbage input, right?
That should still be handled correctly I think.
__cgroup_bpf_run_filter_getsockopt (via sockopt_alloc_buf) should handle both cases correctly:
- garbage input / partial copy resulting in negative number -> EINVAL
- garbage input / partial copy resulting in too large number -> potentially
EFAULT when trying to copy PAGE_SIZE-worth of data
Also, for the EOPNOTSUPP case, we shouldn't even bother copying any data.
Am I missing something?
next prev parent reply other threads:[~2024-09-11 20:05 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-11 5:04 [PATCH] net: check the return value of the copy_from_sockptr Qianqiang Liu
2024-09-11 6:51 ` D. Wythe
2024-09-11 7:13 ` Eric Dumazet
2024-09-11 8:23 ` Qianqiang Liu
2024-09-11 9:12 ` Eric Dumazet
2024-09-11 10:24 ` Qianqiang Liu
2024-09-11 12:40 ` Eric Dumazet
2024-09-11 16:58 ` Cong Wang
2024-09-11 17:15 ` Eric Dumazet
2024-09-11 17:35 ` Cong Wang
2024-09-11 18:49 ` Stanislav Fomichev
2024-09-11 19:48 ` Cong Wang
2024-09-11 20:05 ` Stanislav Fomichev [this message]
2024-09-14 0:49 ` Cong Wang
2024-09-14 18:01 ` Stanislav Fomichev
2024-09-18 13:11 ` David Laight
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZuH4B7STmaY0AI1m@mini-arch \
--to=stfomichev@gmail.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=qianqiang.liu@163.com \
--cc=xiyou.wangcong@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.