From: Daniel Borkmann <daniel@iogearbox.net>
To: gregkh@linuxfoundation.org
Cc: ast@kernel.org, stable@vger.kernel.org,
Daniel Borkmann <daniel@iogearbox.net>
Subject: [PATCH stable 4.20 05/10] bpf: restrict stack pointer arithmetic for unprivileged
Date: Mon, 28 Jan 2019 21:23:25 +0100 [thread overview]
Message-ID: <20190128202330.32664-6-daniel@iogearbox.net> (raw)
In-Reply-To: <20190128202330.32664-1-daniel@iogearbox.net>
[ commit e4298d25830a866cc0f427d4bccb858e76715859 upstream ]
Restrict stack pointer arithmetic for unprivileged users in that
arithmetic itself must not go out of bounds as opposed to the actual
access later on. Therefore after each adjust_ptr_min_max_vals() with
a stack pointer as a destination we simulate a check_stack_access()
of 1 byte on the destination and once that fails the program is
rejected for unprivileged program loads. This is analog to map
value pointer arithmetic and needed for masking later on.
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
---
kernel/bpf/verifier.c | 63 ++++++++++++++++++++++++++++---------------
1 file changed, 41 insertions(+), 22 deletions(-)
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index 517ac90f9e01..288f045cb6a6 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -1314,6 +1314,31 @@ static int check_stack_read(struct bpf_verifier_env *env,
}
}
+static int check_stack_access(struct bpf_verifier_env *env,
+ const struct bpf_reg_state *reg,
+ int off, int size)
+{
+ /* Stack accesses must be at a fixed offset, so that we
+ * can determine what type of data were returned. See
+ * check_stack_read().
+ */
+ if (!tnum_is_const(reg->var_off)) {
+ char tn_buf[48];
+
+ tnum_strn(tn_buf, sizeof(tn_buf), reg->var_off);
+ verbose(env, "variable stack access var_off=%s off=%d size=%d",
+ tn_buf, off, size);
+ return -EACCES;
+ }
+
+ if (off >= 0 || off < -MAX_BPF_STACK) {
+ verbose(env, "invalid stack off=%d size=%d\n", off, size);
+ return -EACCES;
+ }
+
+ return 0;
+}
+
/* check read/write into map element returned by bpf_map_lookup_elem() */
static int __check_map_access(struct bpf_verifier_env *env, u32 regno, int off,
int size, bool zero_size_allowed)
@@ -1870,24 +1895,10 @@ static int check_mem_access(struct bpf_verifier_env *env, int insn_idx, u32 regn
}
} else if (reg->type == PTR_TO_STACK) {
- /* stack accesses must be at a fixed offset, so that we can
- * determine what type of data were returned.
- * See check_stack_read().
- */
- if (!tnum_is_const(reg->var_off)) {
- char tn_buf[48];
-
- tnum_strn(tn_buf, sizeof(tn_buf), reg->var_off);
- verbose(env, "variable stack access var_off=%s off=%d size=%d",
- tn_buf, off, size);
- return -EACCES;
- }
off += reg->var_off.value;
- if (off >= 0 || off < -MAX_BPF_STACK) {
- verbose(env, "invalid stack off=%d size=%d\n", off,
- size);
- return -EACCES;
- }
+ err = check_stack_access(env, reg, off, size);
+ if (err)
+ return err;
state = func(env, reg);
err = update_stack_depth(env, state, off);
@@ -3169,11 +3180,19 @@ static int adjust_ptr_min_max_vals(struct bpf_verifier_env *env,
/* For unprivileged we require that resulting offset must be in bounds
* in order to be able to sanitize access later on.
*/
- if (!env->allow_ptr_leaks && dst_reg->type == PTR_TO_MAP_VALUE &&
- check_map_access(env, dst, dst_reg->off, 1, false)) {
- verbose(env, "R%d pointer arithmetic of map value goes out of range, prohibited for !root\n",
- dst);
- return -EACCES;
+ if (!env->allow_ptr_leaks) {
+ if (dst_reg->type == PTR_TO_MAP_VALUE &&
+ check_map_access(env, dst, dst_reg->off, 1, false)) {
+ verbose(env, "R%d pointer arithmetic of map value goes out of range, "
+ "prohibited for !root\n", dst);
+ return -EACCES;
+ } else if (dst_reg->type == PTR_TO_STACK &&
+ check_stack_access(env, dst_reg, dst_reg->off +
+ dst_reg->var_off.value, 1)) {
+ verbose(env, "R%d stack pointer arithmetic goes out of range, "
+ "prohibited for !root\n", dst);
+ return -EACCES;
+ }
}
return 0;
--
2.17.1
next prev parent reply other threads:[~2019-01-28 20:23 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-28 20:23 [PATCH stable 4.20 00/10] BPF stable fixes Daniel Borkmann
2019-01-28 20:23 ` [PATCH stable 4.20 01/10] bpf: move {prev_,}insn_idx into verifier env Daniel Borkmann
2019-01-28 20:23 ` [PATCH stable 4.20 02/10] bpf: move tmp variable into ax register in interpreter Daniel Borkmann
2019-01-28 20:23 ` [PATCH stable 4.20 03/10] bpf: enable access to ax register also from verifier rewrite Daniel Borkmann
2019-01-28 20:23 ` [PATCH stable 4.20 04/10] bpf: restrict map value pointer arithmetic for unprivileged Daniel Borkmann
2019-01-28 20:23 ` Daniel Borkmann [this message]
2019-01-28 20:23 ` [PATCH stable 4.20 06/10] bpf: restrict unknown scalars of mixed signed bounds " Daniel Borkmann
2019-01-28 20:23 ` [PATCH stable 4.20 07/10] bpf: fix check_map_access smin_value test when pointer contains offset Daniel Borkmann
2019-01-28 20:23 ` [PATCH stable 4.20 08/10] bpf: prevent out of bounds speculation on pointer arithmetic Daniel Borkmann
2019-01-28 20:23 ` [PATCH stable 4.20 09/10] bpf: fix sanitation of alu op with pointer / scalar type from different paths Daniel Borkmann
2019-01-28 20:23 ` [PATCH stable 4.20 10/10] bpf: fix inner map masking to prevent oob under speculation Daniel Borkmann
2019-01-28 21:19 ` [PATCH stable 4.20 00/10] BPF stable fixes Sasha Levin
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=20190128202330.32664-6-daniel@iogearbox.net \
--to=daniel@iogearbox.net \
--cc=ast@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=stable@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