Received: by 10.223.176.5 with SMTP id f5csp3389397wra; Mon, 29 Jan 2018 12:29:09 -0800 (PST) X-Google-Smtp-Source: AH8x22637Evx0LbDuQYeSdw1zRkNZZqoq9KMGSky50MImv8UODBjdCo0WL8V6EwAPQHI8+Mf/YoP X-Received: by 10.98.196.205 with SMTP id h74mr27877226pfk.129.1517257749866; Mon, 29 Jan 2018 12:29:09 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1517257749; cv=none; d=google.com; s=arc-20160816; b=tUWTxJvzpDc2knpGT0gY8zVsqvXIW/Ybdd6I8kZCBiNom/VMaYC5EG1LUcjawbqTD5 daLMkuUbdltOHoTya8HkODFUsgWjjJokdWJWlKqDR3LWGUpzIemHMQkjLDj5lkHiIZLt JrrllEK1VLav3Q6oy58LeyGc86FWLmeKt5+cnHODlbPI1wpYJayWU3oGEertDuYpMFOE XuFUw3Qqk4/MqDtZNtxfKJbHOrf5hFrty+R2Pnm6FnOPaT2nyBPBQwcs4ih7z6RfQtXM eRY9Qh3xud5hdCX16nstyyx4oZEheedxG1x0UB5Bea2m5SCMevMf/NqQpwhAMH4XvWSF mrXA== 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=UFqkX9WM+FBS0ZBjyzry9Un4zdrQebrqfcuBCJfwkZ4=; b=ui3AHK9Um7C9oDY1pTxj0UK0zSfxxIMzWs80LlhoQVR8ChWSBjG7vHM855/EKY4EK/ uEI1DhJMMyuD5437Hu0gP3BxfrWpwzfwGGPYKQKRPBiJCt1jTgiPWSPk06SIQfxOVNQD VuPqr8JdCEuLZnaKOITHsddCS4b+RDxXdKAZ8DsDwuu8VzNrtOMsuPmZoyXkxeGSAFZF qpZDhdK5WKkwxzUW9QNGbtq7l1zBYHfIPGjld1aM/lIn8mYXieDE02oVe9tvKEsCCOCW DjBSQElzUGV/Mgk2eIH62tBOdP+uadhvAbqaVAucNzUJVQgz4F+wTDWyrRFajmjpV4cV lF0Q== 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 e11si7884895pgp.76.2018.01.29.12.28.55; Mon, 29 Jan 2018 12:29:09 -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 S1753556AbeA2UQK (ORCPT + 99 others); Mon, 29 Jan 2018 15:16:10 -0500 Received: from mail.linuxfoundation.org ([140.211.169.12]:43454 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754419AbeA2UP4 (ORCPT ); Mon, 29 Jan 2018 15:15:56 -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 49D1B2FE0; Mon, 29 Jan 2018 13:08:01 +0000 (UTC) From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Russell King Subject: [PATCH 4.14 15/71] ARM: net: bpf: fix tail call jumps Date: Mon, 29 Jan 2018 13:56:43 +0100 Message-Id: <20180129123828.315103969@linuxfoundation.org> X-Mailer: git-send-email 2.16.1 In-Reply-To: <20180129123827.271171825@linuxfoundation.org> References: <20180129123827.271171825@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.14-stable review patch. If anyone has any objections, please let me know. ------------------ From: Russell King commit f4483f2cc1fdc03488c8a1452e545545ae5bda93 upstream. When a tail call fails, it is documented that the tail call should continue execution at the following instruction. An example tail call sequence is: 12: (85) call bpf_tail_call#12 13: (b7) r0 = 0 14: (95) exit The ARM assembler for the tail call in this case ends up branching to instruction 14 instead of instruction 13, resulting in the BPF filter returning a non-zero value: 178: ldr r8, [sp, #588] ; insn 12 17c: ldr r6, [r8, r6] 180: ldr r8, [sp, #580] 184: cmp r8, r6 188: bcs 0x1e8 18c: ldr r6, [sp, #524] 190: ldr r7, [sp, #528] 194: cmp r7, #0 198: cmpeq r6, #32 19c: bhi 0x1e8 1a0: adds r6, r6, #1 1a4: adc r7, r7, #0 1a8: str r6, [sp, #524] 1ac: str r7, [sp, #528] 1b0: mov r6, #104 1b4: ldr r8, [sp, #588] 1b8: add r6, r8, r6 1bc: ldr r8, [sp, #580] 1c0: lsl r7, r8, #2 1c4: ldr r6, [r6, r7] 1c8: cmp r6, #0 1cc: beq 0x1e8 1d0: mov r8, #32 1d4: ldr r6, [r6, r8] 1d8: add r6, r6, #44 1dc: bx r6 1e0: mov r0, #0 ; insn 13 1e4: mov r1, #0 1e8: add sp, sp, #596 ; insn 14 1ec: pop {r4, r5, r6, r7, r8, sl, pc} For other sequences, the tail call could end up branching midway through the following BPF instructions, or maybe off the end of the function, leading to unknown behaviours. Fixes: 39c13c204bb1 ("arm: eBPF JIT compiler") Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman --- arch/arm/net/bpf_jit_32.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/arm/net/bpf_jit_32.c +++ b/arch/arm/net/bpf_jit_32.c @@ -949,7 +949,7 @@ static int emit_bpf_tail_call(struct jit const u8 *tcc = bpf2a32[TCALL_CNT]; const int idx0 = ctx->idx; #define cur_offset (ctx->idx - idx0) -#define jmp_offset (out_offset - (cur_offset)) +#define jmp_offset (out_offset - (cur_offset) - 2) u32 off, lo, hi; /* if (index >= array->map.max_entries)