From: Stanislav Fomichev <sdf@google.com>
To: netdev@vger.kernel.org, bpf@vger.kernel.org
Cc: davem@davemloft.net, ast@kernel.org, daniel@iogearbox.net,
Stanislav Fomichev <sdf@google.com>,
David Laight <David.Laight@ACULAB.COM>
Subject: [PATCH bpf v3 1/2] bpf: don't return EINVAL from {get,set}sockopt when optlen > PAGE_SIZE
Date: Mon, 8 Jun 2020 11:27:47 -0700 [thread overview]
Message-ID: <20200608182748.6998-1-sdf@google.com> (raw)
Attaching to these hooks can break iptables because its optval is
usually quite big, or at least bigger than the current PAGE_SIZE limit.
David also mentioned some SCTP options can be big (around 256k).
There are two possible ways to fix it:
1. Increase the limit to match iptables max optval. There is, however,
no clear upper limit. Technically, iptables can accept up to
512M of data (not sure how practical it is though).
2. Bypass the value (don't expose to BPF) if it's too big and trigger
BPF only with level/optname so BPF can still decide whether
to allow/deny big sockopts.
The initial attempt was implemented using strategy #1. Due to
listed shortcomings, let's switch to strategy #2. When there is
legitimate a real use-case for iptables/SCTP, we can consider increasing
the PAGE_SIZE limit.
v3:
* don't increase the limit, bypass the argument
v2:
* proper comments formatting (Jakub Kicinski)
Fixes: 0d01da6afc54 ("bpf: implement getsockopt and setsockopt hooks")
Cc: David Laight <David.Laight@ACULAB.COM>
Signed-off-by: Stanislav Fomichev <sdf@google.com>
---
kernel/bpf/cgroup.c | 18 ++++++++++++++----
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/kernel/bpf/cgroup.c b/kernel/bpf/cgroup.c
index fdf7836750a3..758082853086 100644
--- a/kernel/bpf/cgroup.c
+++ b/kernel/bpf/cgroup.c
@@ -1276,9 +1276,18 @@ static bool __cgroup_bpf_prog_array_is_empty(struct cgroup *cgrp,
static int sockopt_alloc_buf(struct bpf_sockopt_kern *ctx, int max_optlen)
{
- if (unlikely(max_optlen > PAGE_SIZE) || max_optlen < 0)
+ if (unlikely(max_optlen < 0))
return -EINVAL;
+ if (unlikely(max_optlen > PAGE_SIZE)) {
+ /* We don't expose optvals that are greater than PAGE_SIZE
+ * to the BPF program.
+ */
+ ctx->optval = NULL;
+ ctx->optval_end = NULL;
+ return 0;
+ }
+
ctx->optval = kzalloc(max_optlen, GFP_USER);
if (!ctx->optval)
return -ENOMEM;
@@ -1325,7 +1334,7 @@ int __cgroup_bpf_run_filter_setsockopt(struct sock *sk, int *level,
ctx.optlen = *optlen;
- if (copy_from_user(ctx.optval, optval, *optlen) != 0) {
+ if (ctx.optval && copy_from_user(ctx.optval, optval, *optlen) != 0) {
ret = -EFAULT;
goto out;
}
@@ -1407,7 +1416,8 @@ int __cgroup_bpf_run_filter_getsockopt(struct sock *sk, int level,
if (ctx.optlen > max_optlen)
ctx.optlen = max_optlen;
- if (copy_from_user(ctx.optval, optval, ctx.optlen) != 0) {
+ if (ctx.optval &&
+ copy_from_user(ctx.optval, optval, ctx.optlen) != 0) {
ret = -EFAULT;
goto out;
}
@@ -1436,7 +1446,7 @@ int __cgroup_bpf_run_filter_getsockopt(struct sock *sk, int level,
goto out;
}
- if (copy_to_user(optval, ctx.optval, ctx.optlen) ||
+ if ((ctx.optval && copy_to_user(optval, ctx.optval, ctx.optlen)) ||
put_user(ctx.optlen, optlen)) {
ret = -EFAULT;
goto out;
--
2.27.0.278.ge193c7cf3a9-goog
next reply other threads:[~2020-06-08 18:27 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-08 18:27 Stanislav Fomichev [this message]
2020-06-08 18:27 ` [PATCH bpf v3 2/2] selftests/bpf: make sure optvals > PAGE_SIZE are bypassed Stanislav Fomichev
2020-06-13 0:33 ` [PATCH bpf v3 1/2] bpf: don't return EINVAL from {get,set}sockopt when optlen > PAGE_SIZE Alexei Starovoitov
2020-06-13 1:03 ` Stanislav Fomichev
2020-06-13 3:50 ` Alexei Starovoitov
2020-06-15 16:41 ` Stanislav Fomichev
2020-06-16 23:03 ` Alexei Starovoitov
2020-06-16 23:20 ` Stanislav Fomichev
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=20200608182748.6998-1-sdf@google.com \
--to=sdf@google.com \
--cc=David.Laight@ACULAB.COM \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=netdev@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).