Received: by 10.223.176.5 with SMTP id f5csp1065088wra; Fri, 2 Feb 2018 10:33:46 -0800 (PST) X-Google-Smtp-Source: AH8x226qmRxeqxFUJ/Vn0ceFmrE+QxCmWfKojERp3f9eZ1jFeyhCUm/6iqDaqN/mKQFbomQu1GOB X-Received: by 10.101.98.193 with SMTP id m1mr27445613pgv.174.1517596426866; Fri, 02 Feb 2018 10:33:46 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1517596426; cv=none; d=google.com; s=arc-20160816; b=CCO4qF7xaXn4OhJ8iXxbkmSFOmwCpB9jOWepsNt6bbQXmOX4hjKPqV06/TXKRF0h0A nmcbz+7sn68hyMVLeTUrRUuXDKM2z6ZOMRDFmutKVCrON6W3WFXAZ3Y7HJZbrZzaB1zg VhACIMDIrnjAxlL7g1i0spvuveOoDQyG2pk80+z2NzODASBnXcaKXzNuLJ3LQtBl5qiY bZjyJiSXJp2vtaX1DVuIWk5VXgpx1HhJPzciSqzYztsozhW75xntjMxQjPFhsduxAGXu ZPahJDX+Ohj+A2jMibRri4epqx4sJb1eV1GBt0FJl9RLsK/v9BtEPJp/j0q1ciC/BsfD kkoQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :in-reply-to:message-id:date:subject:cc:to:from :arc-authentication-results; bh=Yw4zwvKxmuTTvB2YYoDKKiSN98OMjVzs/c8pTdnjbxo=; b=G3dibc1ZAeFMM3RSYsyIFr4zaAJOm/9MmXXTXhGpD82STCMLzsp4oOnAuc2WzJiaj/ g+KqL5u5E9paOW6Bl5FvaYjDVYgUY92OIdbK7hv2IHCqnePIcSlJNu1zIaLHglTR+wlG k4VHFkbD778JtwUYNpFt0XpXkoe7DFuZPQn8m+EQ8E9DLIfv1dZ5nx8wumO2FSKXCgRB xYkEEEaiHU+JWuvNzMzcLAIgYpDmrUpOE4u2jOQ7WA0eKjcZUxqPBnF50DzyB6ZfhCSv vhys+fMafrafVf8AGDtUVd+h85olcio78PLJvZdF9hJAuFUWHny2xwCWS9K1LKc6wfyD yTKA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 94-v6si2293543ple.298.2018.02.02.10.33.31; Fri, 02 Feb 2018 10:33:46 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755128AbeBBSbz (ORCPT + 99 others); Fri, 2 Feb 2018 13:31:55 -0500 Received: from mail.linuxfoundation.org ([140.211.169.12]:34630 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752555AbeBBRAG (ORCPT ); Fri, 2 Feb 2018 12:00:06 -0500 Received: from localhost (LFbn-1-12258-90.w90-92.abo.wanadoo.fr [90.92.71.90]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id D4635DCF; Fri, 2 Feb 2018 17:00:04 +0000 (UTC) From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Alexei Starovoitov , Daniel Borkmann Subject: [PATCH 4.4 02/67] bpf: fix branch pruning logic Date: Fri, 2 Feb 2018 17:57:31 +0100 Message-Id: <20180202140815.463324737@linuxfoundation.org> X-Mailer: git-send-email 2.16.1 In-Reply-To: <20180202140815.091718203@linuxfoundation.org> References: <20180202140815.091718203@linuxfoundation.org> User-Agent: quilt/0.65 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 4.4-stable review patch. If anyone has any objections, please let me know. ------------------ From: Alexei Starovoitov [ 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 Acked-by: Daniel Borkmann Signed-off-by: Daniel Borkmann Signed-off-by: Greg Kroah-Hartman --- 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);