All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Borkmann <daniel@iogearbox.net>
To: ast@kernel.org
Cc: jannh@google.com, davem@davemloft.net,
	jakub.kicinski@netronome.com, netdev@vger.kernel.org,
	Daniel Borkmann <daniel@iogearbox.net>
Subject: [PATCH bpf v3 4/9] bpf: restrict map value pointer arithmetic for unprivileged
Date: Thu,  3 Jan 2019 00:58:30 +0100	[thread overview]
Message-ID: <20190102235835.3311-5-daniel@iogearbox.net> (raw)
In-Reply-To: <20190102235835.3311-1-daniel@iogearbox.net>

Restrict map value 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
map value pointer as a destination it will simulate a check_map_access()
of 1 byte on the destination and once that fails the program is rejected
for unprivileged program loads. We use this later on for masking any
pointer arithmetic with the remainder of the map value space. The
likelihood of breaking any existing real-world unprivileged eBPF
program is very small for this corner case.

Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
---
 kernel/bpf/verifier.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index afa8515..4da8c73 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -3249,6 +3249,17 @@ static int adjust_ptr_min_max_vals(struct bpf_verifier_env *env,
 	__update_reg_bounds(dst_reg);
 	__reg_deduce_bounds(dst_reg);
 	__reg_bound_offset(dst_reg);
+
+	/* 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;
+	}
+
 	return 0;
 }
 
-- 
2.9.5

  parent reply	other threads:[~2019-01-02 23:58 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-02 23:58 [PATCH bpf v3 0/9] bpf fix to prevent oob under speculation Daniel Borkmann
2019-01-02 23:58 ` [PATCH bpf v3 1/9] bpf: move {prev_,}insn_idx into verifier env Daniel Borkmann
2019-01-02 23:58 ` [PATCH bpf v3 2/9] bpf: move tmp variable into ax register in interpreter Daniel Borkmann
2019-01-02 23:58 ` [PATCH bpf v3 3/9] bpf: enable access to ax register also from verifier rewrite Daniel Borkmann
2019-01-02 23:58 ` Daniel Borkmann [this message]
2019-01-02 23:58 ` [PATCH bpf v3 5/9] bpf: restrict stack pointer arithmetic for unprivileged Daniel Borkmann
2019-01-02 23:58 ` [PATCH bpf v3 6/9] bpf: restrict unknown scalars of mixed signed bounds " Daniel Borkmann
2019-01-02 23:58 ` [PATCH bpf v3 7/9] bpf: fix check_map_access smin_value test when pointer contains offset Daniel Borkmann
2019-01-02 23:58 ` [PATCH bpf v3 8/9] bpf: prevent out of bounds speculation on pointer arithmetic Daniel Borkmann
2019-01-03 21:13   ` Jann Horn
2019-01-03 23:22     ` Daniel Borkmann
2019-01-02 23:58 ` [PATCH bpf v3 9/9] bpf: add various test cases to selftests Daniel Borkmann
2019-01-03  0:08 ` [PATCH bpf v3 0/9] bpf fix to prevent oob under speculation Alexei Starovoitov
2019-01-22 14:36   ` stable backport for the BPF speculation series? [was: Re: [PATCH bpf v3 0/9] bpf fix to prevent oob under speculation] Jann Horn
2019-01-22 16:44     ` stable backport for the BPF speculation series? David Miller
2019-01-23  1:55       ` Daniel Borkmann
2019-01-23 17:04     ` stable backport for the BPF speculation series? [was: Re: [PATCH bpf v3 0/9] bpf fix to prevent oob under speculation] Greg Kroah-Hartman
2019-01-23 17:12       ` Jann Horn
2019-01-24 11:53         ` Daniel Borkmann

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=20190102235835.3311-5-daniel@iogearbox.net \
    --to=daniel@iogearbox.net \
    --cc=ast@kernel.org \
    --cc=davem@davemloft.net \
    --cc=jakub.kicinski@netronome.com \
    --cc=jannh@google.com \
    --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 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.