From: <gregkh@linuxfoundation.org>
To: daniel@iogearbox.net, ast@fb.com, ast@kernel.org,
gregkh@linuxfoundation.org
Cc: <stable@vger.kernel.org>, <stable-commits@vger.kernel.org>
Subject: Patch "bpf: fix branch pruning logic" has been added to the 4.4-stable tree
Date: Thu, 01 Feb 2018 09:07:33 +0100 [thread overview]
Message-ID: <151747245394250@kroah.com> (raw)
In-Reply-To: <c4bc7f798c0e99b4551d3423c294350fc8223714.1517279268.git.daniel@iogearbox.net>
This is a note to let you know that I've just added the patch titled
bpf: fix branch pruning logic
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
bpf-fix-branch-pruning-logic.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From foo@baz Thu Feb 1 09:05:44 CET 2018
From: Daniel Borkmann <daniel@iogearbox.net>
Date: Tue, 30 Jan 2018 03:37:38 +0100
Subject: bpf: fix branch pruning logic
To: gregkh@linuxfoundation.org
Cc: ast@kernel.org, daniel@iogearbox.net, stable@vger.kernel.org
Message-ID: <c4bc7f798c0e99b4551d3423c294350fc8223714.1517279268.git.daniel@iogearbox.net>
From: Alexei Starovoitov <ast@fb.com>
[ Upstream commit c131187db2d3fa2f8bf32fdf4e9a4ef805168467 ]
when the verifier detects that register contains a runtime constant
and it's compared with another constant it will prune exploration
of the branch that is guaranteed not to be taken at runtime.
This is all correct, but malicious program may be constructed
in such a way that it always has a constant comparison and
the other branch is never taken under any conditions.
In this case such path through the program will not be explored
by the verifier. It won't be taken at run-time either, but since
all instructions are JITed the malicious program may cause JITs
to complain about using reserved fields, etc.
To fix the issue we have to track the instructions explored by
the verifier and sanitize instructions that are dead at run time
with NOPs. We cannot reject such dead code, since llvm generates
it for valid C code, since it doesn't do as much data flow
analysis as the verifier does.
Fixes: 17a5267067f3 ("bpf: verifier (add verifier core)")
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
kernel/bpf/verifier.c | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -191,6 +191,7 @@ struct bpf_insn_aux_data {
enum bpf_reg_type ptr_type; /* pointer type for load/store insns */
struct bpf_map *map_ptr; /* pointer for call insn into lookup_elem */
};
+ bool seen; /* this insn was processed by the verifier */
};
#define MAX_USED_MAPS 64 /* max number of maps accessed by one eBPF program */
@@ -1793,6 +1794,7 @@ static int do_check(struct verifier_env
print_bpf_insn(env, insn);
}
+ env->insn_aux_data[insn_idx].seen = true;
if (class == BPF_ALU || class == BPF_ALU64) {
err = check_alu_op(env, insn);
if (err)
@@ -1988,6 +1990,7 @@ process_bpf_exit:
return err;
insn_idx++;
+ env->insn_aux_data[insn_idx].seen = true;
} else {
verbose("invalid BPF_LD mode\n");
return -EINVAL;
@@ -2125,6 +2128,7 @@ static int adjust_insn_aux_data(struct v
u32 off, u32 cnt)
{
struct bpf_insn_aux_data *new_data, *old_data = env->insn_aux_data;
+ int i;
if (cnt == 1)
return 0;
@@ -2134,6 +2138,8 @@ static int adjust_insn_aux_data(struct v
memcpy(new_data, old_data, sizeof(struct bpf_insn_aux_data) * off);
memcpy(new_data + off + cnt - 1, old_data + off,
sizeof(struct bpf_insn_aux_data) * (prog_len - off - cnt + 1));
+ for (i = off; i < off + cnt - 1; i++)
+ new_data[i].seen = true;
env->insn_aux_data = new_data;
vfree(old_data);
return 0;
@@ -2152,6 +2158,25 @@ static struct bpf_prog *bpf_patch_insn_d
return new_prog;
}
+/* The verifier does more data flow analysis than llvm and will not explore
+ * branches that are dead at run time. Malicious programs can have dead code
+ * too. Therefore replace all dead at-run-time code with nops.
+ */
+static void sanitize_dead_code(struct verifier_env *env)
+{
+ struct bpf_insn_aux_data *aux_data = env->insn_aux_data;
+ struct bpf_insn nop = BPF_MOV64_REG(BPF_REG_0, BPF_REG_0);
+ struct bpf_insn *insn = env->prog->insnsi;
+ const int insn_cnt = env->prog->len;
+ int i;
+
+ for (i = 0; i < insn_cnt; i++) {
+ if (aux_data[i].seen)
+ continue;
+ memcpy(insn + i, &nop, sizeof(nop));
+ }
+}
+
/* convert load instructions that access fields of 'struct __sk_buff'
* into sequence of instructions that access fields of 'struct sk_buff'
*/
@@ -2371,6 +2396,9 @@ skip_full_check:
free_states(env);
if (ret == 0)
+ sanitize_dead_code(env);
+
+ if (ret == 0)
/* program is valid, convert *(u32*)(ctx + off) accesses */
ret = convert_ctx_accesses(env);
Patches currently in stable-queue which might be from daniel@iogearbox.net are
queue-4.4/bpf-fix-branch-pruning-logic.patch
queue-4.4/bpf-avoid-false-sharing-of-map-refcount-with-max_entries.patch
queue-4.4/x86-bpf_jit-small-optimization-in-emit_bpf_tail_call.patch
queue-4.4/bpf-reject-stores-into-ctx-via-st-and-xadd.patch
queue-4.4/bpf-fix-32-bit-divide-by-zero.patch
queue-4.4/bpf-fix-bpf_tail_call-x64-jit.patch
queue-4.4/bpf-arsh-is-not-supported-in-32-bit-alu-thus-reject-it.patch
queue-4.4/bpf-fix-divides-by-zero.patch
queue-4.4/bpf-introduce-bpf_jit_always_on-config.patch
next prev parent reply other threads:[~2018-02-01 8:07 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-30 2:37 [PATCH stable 4.4 0/9] BPF stable patches Daniel Borkmann
2018-01-30 2:37 ` [PATCH stable 4.4 1/9] bpf: fix branch pruning logic Daniel Borkmann
2018-02-01 8:07 ` gregkh [this message]
2018-01-30 2:37 ` [PATCH stable 4.4 2/9] x86: bpf_jit: small optimization in emit_bpf_tail_call() Daniel Borkmann
2018-02-01 8:07 ` Patch "x86: bpf_jit: small optimization in emit_bpf_tail_call()" has been added to the 4.4-stable tree gregkh
2018-01-30 2:37 ` [PATCH stable 4.4 3/9] bpf: fix bpf_tail_call() x64 JIT Daniel Borkmann
2018-02-01 8:07 ` Patch "bpf: fix bpf_tail_call() x64 JIT" has been added to the 4.4-stable tree gregkh
2018-01-30 2:37 ` [PATCH stable 4.4 4/9] bpf: introduce BPF_JIT_ALWAYS_ON config Daniel Borkmann
2018-02-01 8:07 ` Patch "bpf: introduce BPF_JIT_ALWAYS_ON config" has been added to the 4.4-stable tree gregkh
2018-01-30 2:37 ` [PATCH stable 4.4 5/9] bpf: arsh is not supported in 32 bit alu thus reject it Daniel Borkmann
2018-02-01 8:07 ` Patch "bpf: arsh is not supported in 32 bit alu thus reject it" has been added to the 4.4-stable tree gregkh
2018-01-30 2:37 ` [PATCH stable 4.4 6/9] bpf: avoid false sharing of map refcount with max_entries Daniel Borkmann
2018-02-01 8:07 ` Patch "bpf: avoid false sharing of map refcount with max_entries" has been added to the 4.4-stable tree gregkh
2018-01-30 2:37 ` [PATCH stable 4.4 7/9] bpf: fix divides by zero Daniel Borkmann
2018-02-01 8:07 ` Patch "bpf: fix divides by zero" has been added to the 4.4-stable tree gregkh
2018-01-30 2:37 ` [PATCH stable 4.4 8/9] bpf: fix 32-bit divide by zero Daniel Borkmann
2018-02-01 8:07 ` Patch "bpf: fix 32-bit divide by zero" has been added to the 4.4-stable tree gregkh
2018-01-30 2:37 ` [PATCH stable 4.4 9/9] bpf: reject stores into ctx via st and xadd Daniel Borkmann
2018-02-01 8:07 ` Patch "bpf: reject stores into ctx via st and xadd" has been added to the 4.4-stable tree gregkh
2018-01-30 6:30 ` [PATCH stable 4.4 0/9] BPF stable patches Greg KH
2018-01-30 10:29 ` Daniel Borkmann
2018-02-01 8:07 ` Greg KH
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=151747245394250@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=ast@fb.com \
--cc=ast@kernel.org \
--cc=daniel@iogearbox.net \
--cc=stable-commits@vger.kernel.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 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.