Received: by 2002:a6b:fb09:0:0:0:0:0 with SMTP id h9csp2907172iog; Mon, 27 Jun 2022 05:31:53 -0700 (PDT) X-Google-Smtp-Source: AGRyM1tk8Kcalp9ELg0zOzPuVRN2e0sTqdkQzu3kT34/RbNLwP2GQ0J7az9DGP3lJd7DUn2J4gV2 X-Received: by 2002:a17:902:900c:b0:16a:4521:10fd with SMTP id a12-20020a170902900c00b0016a452110fdmr14397524plp.75.1656333112791; Mon, 27 Jun 2022 05:31:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1656333112; cv=none; d=google.com; s=arc-20160816; b=WXrsQb50DudSYWEWqDpY7/7II9zMPAp4Xcz8WKS2KTnMsrgpFn2LUxE/iHSoutKvhS wpC9nCUys7TpkLurQAJSs1qRId+PK+AjxqKDbQWjTaFZtusm6m+UrAxSLUzicaTIB1Tl J4by76+GuJHu02eq8UrujuKT4HsQcscZ5m4sIPIl8Byu0w/+vBxuzHZE7hshgkzJG2vs u47CLIbt38D8VS6hp8aifRl+vDZnYN2bzfSX9RaUykH8L8cQyXjYuUhy4FH0ZHRhlDAo ftNGvZI9mcJvcipbt0Izlm283HRlM+UFLG7WS/K81A1IWLEcNGvu3tiBnkrCMhExa9C1 VrHA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=2oOpqg3gV3JsjUMEGulEMl1cL355ZnrBApzgpliJcnU=; b=feBud3OvOqIEuGAMhArATk/etdDqv/3lRG/TEjK/RHmzam6t2xRi3W0kPDVdJyjL+e yqQ6JpxISrqr03d1aSzLFAIPWIcSIwVLtlDlZRZB3S0OLcVQSD1lwqKcIMjIWxAC7LhG PVYes9tm6G1CbPrK0oDJLEcKklQvpJHy5VJDPLPF6Agele0CrpdbQYgQBF1Ox4lkZr8b r+YvwK7D1Kz2/71lpNTSikPBhPgBICD20Ig7Vbmfcp5LBqZW+ruFWOURE6pWuzr5wtmm SfROt4z7KizCf0vCQdRLb4BdtsGImygGnqG5NkTcrVzRt4dB9NlwEWj94L0t/Fp+CVVd +KKQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=UNtIBjLM; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id n24-20020a17090ac69800b001eafa7ad6e4si12724721pjt.29.2022.06.27.05.31.40; Mon, 27 Jun 2022 05:31:52 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=UNtIBjLM; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239109AbiF0Lyv (ORCPT + 99 others); Mon, 27 Jun 2022 07:54:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50094 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238526AbiF0Lsn (ORCPT ); Mon, 27 Jun 2022 07:48:43 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CBB0DCE01; Mon, 27 Jun 2022 04:42:06 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 53B91B80D32; Mon, 27 Jun 2022 11:42:05 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id ADCB3C341C7; Mon, 27 Jun 2022 11:42:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1656330124; bh=Q5L49TpOIeo3P/N2thDwkriqVymsydDLChQXHGGL/vc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=UNtIBjLM9An+tdvUBitAode+pZk85LbCR9kU42n8n6ZJUxMwnEfA6JWYddolsDQVD 98C3QvHAgPrab6IkiIcM9ErXtI8Te4wQYXREOAQvzPUAKePufh+nkQd2XGQk6cQEWm bSsLVb74GoPrA0NYHl3L9/myAUbE/prEGDo3aYSw= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Jakub Sitnicki , Daniel Borkmann , Maciej Fijalkowski , Sasha Levin Subject: [PATCH 5.18 052/181] bpf, x86: Fix tail call count offset calculation on bpf2bpf call Date: Mon, 27 Jun 2022 13:20:25 +0200 Message-Id: <20220627111946.075705044@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220627111944.553492442@linuxfoundation.org> References: <20220627111944.553492442@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.5 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Jakub Sitnicki [ Upstream commit ff672c67ee7635ca1e28fb13729e8ef0d1f08ce5 ] On x86-64 the tail call count is passed from one BPF function to another through %rax. Additionally, on function entry, the tail call count value is stored on stack right after the BPF program stack, due to register shortage. The stored count is later loaded from stack either when performing a tail call - to check if we have not reached the tail call limit - or before calling another BPF function call in order to pass it via %rax. In the latter case, we miscalculate the offset at which the tail call count was stored on function entry. The JIT does not take into account that the allocated BPF program stack is always a multiple of 8 on x86, while the actual stack depth does not have to be. This leads to a load from an offset that belongs to the BPF stack, as shown in the example below: SEC("tc") int entry(struct __sk_buff *skb) { /* Have data on stack which size is not a multiple of 8 */ volatile char arr[1] = {}; return subprog_tail(skb); } int entry(struct __sk_buff * skb): 0: (b4) w2 = 0 1: (73) *(u8 *)(r10 -1) = r2 2: (85) call pc+1#bpf_prog_ce2f79bb5f3e06dd_F 3: (95) exit int entry(struct __sk_buff * skb): 0xffffffffa0201788: nop DWORD PTR [rax+rax*1+0x0] 0xffffffffa020178d: xor eax,eax 0xffffffffa020178f: push rbp 0xffffffffa0201790: mov rbp,rsp 0xffffffffa0201793: sub rsp,0x8 0xffffffffa020179a: push rax 0xffffffffa020179b: xor esi,esi 0xffffffffa020179d: mov BYTE PTR [rbp-0x1],sil 0xffffffffa02017a1: mov rax,QWORD PTR [rbp-0x9] !!! tail call count 0xffffffffa02017a8: call 0xffffffffa02017d8 !!! is at rbp-0x10 0xffffffffa02017ad: leave 0xffffffffa02017ae: ret Fix it by rounding up the BPF stack depth to a multiple of 8, when calculating the tail call count offset on stack. Fixes: ebf7d1f508a7 ("bpf, x64: rework pro/epilogue and tailcall handling in JIT") Signed-off-by: Jakub Sitnicki Signed-off-by: Daniel Borkmann Acked-by: Maciej Fijalkowski Acked-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20220616162037.535469-2-jakub@cloudflare.com Signed-off-by: Sasha Levin --- arch/x86/net/bpf_jit_comp.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c index 16b6efacf7c6..4c71fa04e784 100644 --- a/arch/x86/net/bpf_jit_comp.c +++ b/arch/x86/net/bpf_jit_comp.c @@ -1415,8 +1415,9 @@ st: if (is_imm8(insn->off)) case BPF_JMP | BPF_CALL: func = (u8 *) __bpf_call_base + imm32; if (tail_call_reachable) { + /* mov rax, qword ptr [rbp - rounded_stack_depth - 8] */ EMIT3_off32(0x48, 0x8B, 0x85, - -(bpf_prog->aux->stack_depth + 8)); + -round_up(bpf_prog->aux->stack_depth, 8) - 8); if (!imm32 || emit_call(&prog, func, image + addrs[i - 1] + 7)) return -EINVAL; } else { -- 2.35.1