From: Alexei Starovoitov <ast@kernel.org>
To: "David S . Miller" <davem@davemloft.net>
Cc: Daniel Borkmann <daniel@iogearbox.net>,
Jann Horn <jannh@google.com>, Edward Cree <ecree@solarflare.com>,
<netdev@vger.kernel.org>, <kernel-team@fb.com>
Subject: [PATCH bpf 1/9] bpf/verifier: fix bounds calculation on BPF_RSH
Date: Mon, 18 Dec 2017 20:11:53 -0800 [thread overview]
Message-ID: <20171219041201.1979983-2-ast@kernel.org> (raw)
In-Reply-To: <20171219041201.1979983-1-ast@kernel.org>
From: Edward Cree <ecree@solarflare.com>
Incorrect signed bounds were being computed.
If the old upper signed bound was positive and the old lower signed bound was
negative, this could cause the new upper signed bound to be too low,
leading to security issues.
Fixes: b03c9f9fdc37 ("bpf/verifier: track signed and unsigned min/max values")
Reported-by: Jann Horn <jannh@google.com>
Signed-off-by: Edward Cree <ecree@solarflare.com>
Acked-by: Alexei Starovoitov <ast@kernel.org>
[jannh@google.com: changed description to reflect bug impact]
Signed-off-by: Jann Horn <jannh@google.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
---
kernel/bpf/verifier.c | 30 ++++++++++++++++--------------
1 file changed, 16 insertions(+), 14 deletions(-)
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index e39b01317b6f..625e358ca765 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -2190,20 +2190,22 @@ static int adjust_scalar_min_max_vals(struct bpf_verifier_env *env,
mark_reg_unknown(env, regs, insn->dst_reg);
break;
}
- /* BPF_RSH is an unsigned shift, so make the appropriate casts */
- if (dst_reg->smin_value < 0) {
- if (umin_val) {
- /* Sign bit will be cleared */
- dst_reg->smin_value = 0;
- } else {
- /* Lost sign bit information */
- dst_reg->smin_value = S64_MIN;
- dst_reg->smax_value = S64_MAX;
- }
- } else {
- dst_reg->smin_value =
- (u64)(dst_reg->smin_value) >> umax_val;
- }
+ /* BPF_RSH is an unsigned shift. If the value in dst_reg might
+ * be negative, then either:
+ * 1) src_reg might be zero, so the sign bit of the result is
+ * unknown, so we lose our signed bounds
+ * 2) it's known negative, thus the unsigned bounds capture the
+ * signed bounds
+ * 3) the signed bounds cross zero, so they tell us nothing
+ * about the result
+ * If the value in dst_reg is known nonnegative, then again the
+ * unsigned bounts capture the signed bounds.
+ * Thus, in all cases it suffices to blow away our signed bounds
+ * and rely on inferring new ones from the unsigned bounds and
+ * var_off of the result.
+ */
+ dst_reg->smin_value = S64_MIN;
+ dst_reg->smax_value = S64_MAX;
if (src_known)
dst_reg->var_off = tnum_rshift(dst_reg->var_off,
umin_val);
--
2.9.5
next prev parent reply other threads:[~2017-12-19 4:12 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-19 4:11 [PATCH bpf 0/9] bpf: verifier security fixes Alexei Starovoitov
2017-12-19 4:11 ` Alexei Starovoitov [this message]
2017-12-19 4:11 ` [PATCH bpf 2/9] bpf: fix incorrect sign extension in check_alu_op() Alexei Starovoitov
2017-12-19 4:11 ` [PATCH bpf 3/9] bpf: fix incorrect tracking of register size truncation Alexei Starovoitov
2017-12-19 4:11 ` [PATCH bpf 4/9] bpf: fix 32-bit ALU op verification Alexei Starovoitov
2017-12-19 4:11 ` [PATCH bpf 5/9] bpf: fix missing error return in check_stack_boundary() Alexei Starovoitov
2017-12-19 4:11 ` [PATCH bpf 6/9] bpf: force strict alignment checks for stack pointers Alexei Starovoitov
2017-12-19 4:11 ` [PATCH bpf 7/9] bpf: don't prune branches when a scalar is replaced with a pointer Alexei Starovoitov
2017-12-19 4:12 ` [PATCH bpf 8/9] bpf: fix integer overflows Alexei Starovoitov
2017-12-19 10:29 ` Edward Cree
2017-12-19 19:57 ` Alexei Starovoitov
2017-12-19 4:12 ` [PATCH bpf 9/9] selftests/bpf: add tests for recent bugfixes Alexei Starovoitov
2017-12-21 2:20 ` [PATCH bpf 0/9] bpf: verifier security fixes 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=20171219041201.1979983-2-ast@kernel.org \
--to=ast@kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=ecree@solarflare.com \
--cc=jannh@google.com \
--cc=kernel-team@fb.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 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).