Received: by 2002:a6b:fb09:0:0:0:0:0 with SMTP id h9csp2930862iog; Mon, 20 Jun 2022 07:43:56 -0700 (PDT) X-Google-Smtp-Source: AGRyM1s2RptLwh1nK96EnomAXbSFA5Dld2p443QeoWROpuUvOEQHBbZU0iJoJ8CnNQXsJfBUbD2z X-Received: by 2002:a17:902:d586:b0:16a:24de:1964 with SMTP id k6-20020a170902d58600b0016a24de1964mr5769051plh.4.1655736236573; Mon, 20 Jun 2022 07:43:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1655736236; cv=none; d=google.com; s=arc-20160816; b=mTOfS4k+UhxTR3X+dxkROyg1FLQbyqN0SgND2NKgzCZuKlLlNd5LZZDdtwxiWIjs6K 3Qpvd6Xuy2Wq6A6qGNN7daRyEyxer15jpb8LZbl/YWx+DD3K4J4tcUrcinhbKTmZM5x+ T7CLQr16/XMBZP95mqaCaRRjz/23fi1/MC5tvNnmHI9u0MPYQXh7O4xgqUr/98w5yF04 NpaEIfPyjEmLIDYNqQ3FJB7N1xj4Yg7OzSs46ftdWel4UNXcTP1NMM0cItLs7kFmV2aM 5J6Fs7J3c8gy+Vbot7jwnqlr2sbrhMq6buaxsmYFJOv2M4/H3QosaJ3NxwRDsUBiNZ0b 0Wxw== 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=tPccvHDu1Y6ClAfpmOMPY+YP0+yH5v9+b3xxw33vQZ8=; b=Km5kncjrhcrSx8MI/vUk6Yz4Tmnq8Lis4D/xMSq7IAtP4PRMqn3waGoRC0u00WelMu QpRI1M6o9vXTeNoo+JB817R7U6CKrwOzUaMBONXEoEz9nxj2qNf1s/LJ7ZiM1xESW6Ae vBa0t5HYZI6gNkpR1JBFtAHjj3SIc3b36Ez91V77iF/eMczNkPhGnorQJ12zS6xC7ypI kXh60G1bq/6/GiW6YlSSeLNCKDE/gpl0BiCWiR6wUa+LalUO9zpYx552TQrP6CT7fHOf DiQNZ3NFFtO9/pVZHiu+0F/XmBLoBr/C2jCZitcWOyu+b8SNEoa9ahZGXgnaC9CFA02e wbdw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=rvkbPmwt; 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 r14-20020a63204e000000b003c6c6e29bc6si16549644pgm.416.2022.06.20.07.43.44; Mon, 20 Jun 2022 07:43:56 -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=rvkbPmwt; 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 S243900AbiFTNWf (ORCPT + 99 others); Mon, 20 Jun 2022 09:22:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58392 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345821AbiFTNUG (ORCPT ); Mon, 20 Jun 2022 09:20:06 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D806E22295; Mon, 20 Jun 2022 06:08:31 -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 dfw.source.kernel.org (Postfix) with ESMTPS id 1CADE60AC0; Mon, 20 Jun 2022 13:08:31 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 12FEEC3411C; Mon, 20 Jun 2022 13:08:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1655730510; bh=isSkBvF2SKbK+LIjNl9zSIRn10ltWAd3wql8HsAGxhs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=rvkbPmwtWRcakkfXgVGlGm+zwcMCCD+XQhm3/0R1DHeEzSKI6/WM9X7elsMCaEJVh QNewj/BiGz9GrWkCpdy4Y4Y7pbZjDormvFlp0Fz+Xc2nNnicKzzyyHe7+5Ji60/G9a twFWSvhf3KnDTW8X1075b++77noqwxGcCPxo18Vw= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Mark Rutland , Ard Biesheuvel , Will Deacon , "Ivan T. Ivanov" , Chengming Zhou , Catalin Marinas , Sasha Levin Subject: [PATCH 5.15 068/106] arm64: ftrace: fix branch range checks Date: Mon, 20 Jun 2022 14:51:27 +0200 Message-Id: <20220620124726.414289527@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220620124724.380838401@linuxfoundation.org> References: <20220620124724.380838401@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.7 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: Mark Rutland [ Upstream commit 3eefdf9d1e406f3da47470b2854347009ffcb6fa ] The branch range checks in ftrace_make_call() and ftrace_make_nop() are incorrect, erroneously permitting a forwards branch of 128M and erroneously rejecting a backwards branch of 128M. This is because both functions calculate the offset backwards, calculating the offset *from* the target *to* the branch, rather than the other way around as the later comparisons expect. If an out-of-range branch were erroeously permitted, this would later be rejected by aarch64_insn_gen_branch_imm() as branch_imm_common() checks the bounds correctly, resulting in warnings and the placement of a BRK instruction. Note that this can only happen for a forwards branch of exactly 128M, and so the caller would need to be exactly 128M bytes below the relevant ftrace trampoline. If an in-range branch were erroeously rejected, then: * For modules when CONFIG_ARM64_MODULE_PLTS=y, this would result in the use of a PLT entry, which is benign. Note that this is the common case, as this is selected by CONFIG_RANDOMIZE_BASE (and therefore RANDOMIZE_MODULE_REGION_FULL), which distributions typically seelct. This is also selected by CONFIG_ARM64_ERRATUM_843419. * For modules when CONFIG_ARM64_MODULE_PLTS=n, this would result in internal ftrace failures. * For core kernel text, this would result in internal ftrace failues. Note that for this to happen, the kernel text would need to be at least 128M bytes in size, and typical configurations are smaller tha this. Fix this by calculating the offset *from* the branch *to* the target in both functions. Fixes: f8af0b364e24 ("arm64: ftrace: don't validate branch via PLT in ftrace_make_nop()") Fixes: e71a4e1bebaf ("arm64: ftrace: add support for far branches to dynamic ftrace") Signed-off-by: Mark Rutland Cc: Ard Biesheuvel Cc: Will Deacon Tested-by: "Ivan T. Ivanov" Reviewed-by: Chengming Zhou Reviewed-by: Ard Biesheuvel Link: https://lore.kernel.org/r/20220614080944.1349146-2-mark.rutland@arm.com Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin --- arch/arm64/kernel/ftrace.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm64/kernel/ftrace.c b/arch/arm64/kernel/ftrace.c index 7f467bd9db7a..abb6f1bbc2a3 100644 --- a/arch/arm64/kernel/ftrace.c +++ b/arch/arm64/kernel/ftrace.c @@ -84,7 +84,7 @@ int ftrace_make_call(struct dyn_ftrace *rec, unsigned long addr) { unsigned long pc = rec->ip; u32 old, new; - long offset = (long)pc - (long)addr; + long offset = (long)addr - (long)pc; if (offset < -SZ_128M || offset >= SZ_128M) { struct module *mod; @@ -183,7 +183,7 @@ int ftrace_make_nop(struct module *mod, struct dyn_ftrace *rec, unsigned long pc = rec->ip; bool validate = true; u32 old = 0, new; - long offset = (long)pc - (long)addr; + long offset = (long)addr - (long)pc; if (offset < -SZ_128M || offset >= SZ_128M) { u32 replaced; -- 2.35.1