Received: by 2002:a05:6359:c8b:b0:c7:702f:21d4 with SMTP id go11csp2519976rwb; Mon, 3 Oct 2022 01:50:32 -0700 (PDT) X-Google-Smtp-Source: AMsMyM48dTW2l7theqKAJX93+udh3o5ow2hepVsmERNS9HRO40TtwTKnutfFNMPUerKOteb0z19t X-Received: by 2002:a05:6a00:21d1:b0:542:b916:c48f with SMTP id t17-20020a056a0021d100b00542b916c48fmr21873492pfj.56.1664787031697; Mon, 03 Oct 2022 01:50:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1664787031; cv=none; d=google.com; s=arc-20160816; b=xJt9eALTDid8kx1soo9cdBB1hSC3U7qkT0/3EJXBi1AamxsyjJ2rTvv75WZ1pjypL8 S/VlY5tZdo/c0eQ5IWyURQA2uoKYE1/6wYLqSYb8vjgBEzbaLRqhRGBr1puZkqt1vj4+ Hy1s6wlVNf+LfI8d1PNO9aKc/rQsbrzF/JZ2bvM/dNmutDfroImRKgm/11JuxmwRf7xl tnNGnGu9wZtvMD2ELtiK4ur/C6m2BUDabUJzLzFQdEn8NRN4N26E5Boy+kTwVeRrDr1p DOtaZXyjMR84fAIOt1nSHqQG2g7msEE4UhHXJBA0KRULW+n6OHunGTQS8J7iKnHAcZDt khAQ== 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=DlQJLKI+yaazE0gBhePByRElgU0YPusG1ZqdV576PhE=; b=QOqCiAJa89Olh2IuzMUnBZ9PRQKWlwvPgsdQXbEaiFvr5a1kEFbYcr38qX5S8iD3JO CNHIxXBID5L9in+yuYzjMcRSpI0iw4sbm6286c0GN9CE6HweDbHK7CkWIeEfe/asDPYF pZ5wITGtfj6rjKFYxjoXst9+YruHxwe/91T878BJ43cO+FBNq/S9zygenGM04B4Cq1Hn SeB3F1jlZAA0Hc7Wjsw3iterrZPzdEjPrk3p+9k/Z2Dse7Qef0dWTwBxtHV7KmoNZRYr I+QVh4NYufzxMjhf1Iy37HRd6DTeQTkJfnLem7eKKz5P/lnIRVsXu0zEFjUCtynjGXr5 n1Kw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=s75ko5H6; 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 c2-20020aa781c2000000b0053bafb8e916si8784107pfn.162.2022.10.03.01.50.20; Mon, 03 Oct 2022 01:50:31 -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=s75ko5H6; 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 S231843AbiJCHiQ (ORCPT + 99 others); Mon, 3 Oct 2022 03:38:16 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35298 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231691AbiJCHgZ (ORCPT ); Mon, 3 Oct 2022 03:36:25 -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 C18BE53031; Mon, 3 Oct 2022 00:22:43 -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 65218B808BF; Mon, 3 Oct 2022 07:22:36 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C8947C433D6; Mon, 3 Oct 2022 07:22:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1664781755; bh=1z2IDQSNlAHkcaOCrXLMtK7LjHh8gcIkopUvryicfQM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=s75ko5H684/HGo8d9gicp15DRoMPymB8imfmhrc9g5K82xMiGGkka96PrdJqtO1Vk E6JWJun5qO2wSSf1ajOEb3RylcUV+LdmNIl3gbVkDx1g9X4SaHfOcbcXiujE5LLBEs CDxJIl5r0cDbPp16FB1NkSN7wft3gscJu9hZPlKk= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Nadav Amit , "Peter Zijlstra (Intel)" , stable@kernel.org Subject: [PATCH 5.10 51/52] x86/alternative: Fix race in try_get_desc() Date: Mon, 3 Oct 2022 09:11:58 +0200 Message-Id: <20221003070720.238567508@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20221003070718.687440096@linuxfoundation.org> References: <20221003070718.687440096@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.1 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 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: Nadav Amit commit efd608fa7403ba106412b437f873929e2c862e28 upstream. I encountered some occasional crashes of poke_int3_handler() when kprobes are set, while accessing desc->vec. The text poke mechanism claims to have an RCU-like behavior, but it does not appear that there is any quiescent state to ensure that nobody holds reference to desc. As a result, the following race appears to be possible, which can lead to memory corruption. CPU0 CPU1 ---- ---- text_poke_bp_batch() -> smp_store_release(&bp_desc, &desc) [ notice that desc is on the stack ] poke_int3_handler() [ int3 might be kprobe's so sync events are do not help ] -> try_get_desc(descp=&bp_desc) desc = __READ_ONCE(bp_desc) if (!desc) [false, success] WRITE_ONCE(bp_desc, NULL); atomic_dec_and_test(&desc.refs) [ success, desc space on the stack is being reused and might have non-zero value. ] arch_atomic_inc_not_zero(&desc->refs) [ might succeed since desc points to stack memory that was freed and might be reused. ] Fix this issue with small backportable patch. Instead of trying to make RCU-like behavior for bp_desc, just eliminate the unnecessary level of indirection of bp_desc, and hold the whole descriptor as a global. Anyhow, there is only a single descriptor at any given moment. Fixes: 1f676247f36a4 ("x86/alternatives: Implement a better poke_int3_handler() completion scheme") Signed-off-by: Nadav Amit Signed-off-by: Peter Zijlstra (Intel) Cc: stable@kernel.org Link: https://lkml.kernel.org/r/20220920224743.3089-1-namit@vmware.com Signed-off-by: Greg Kroah-Hartman --- arch/x86/kernel/alternative.c | 45 +++++++++++++++++++++--------------------- 1 file changed, 23 insertions(+), 22 deletions(-) --- a/arch/x86/kernel/alternative.c +++ b/arch/x86/kernel/alternative.c @@ -1330,22 +1330,23 @@ struct bp_patching_desc { atomic_t refs; }; -static struct bp_patching_desc *bp_desc; +static struct bp_patching_desc bp_desc; static __always_inline -struct bp_patching_desc *try_get_desc(struct bp_patching_desc **descp) +struct bp_patching_desc *try_get_desc(void) { - /* rcu_dereference */ - struct bp_patching_desc *desc = __READ_ONCE(*descp); + struct bp_patching_desc *desc = &bp_desc; - if (!desc || !arch_atomic_inc_not_zero(&desc->refs)) + if (!arch_atomic_inc_not_zero(&desc->refs)) return NULL; return desc; } -static __always_inline void put_desc(struct bp_patching_desc *desc) +static __always_inline void put_desc(void) { + struct bp_patching_desc *desc = &bp_desc; + smp_mb__before_atomic(); arch_atomic_dec(&desc->refs); } @@ -1378,15 +1379,15 @@ noinstr int poke_int3_handler(struct pt_ /* * Having observed our INT3 instruction, we now must observe - * bp_desc: + * bp_desc with non-zero refcount: * - * bp_desc = desc INT3 + * bp_desc.refs = 1 INT3 * WMB RMB - * write INT3 if (desc) + * write INT3 if (bp_desc.refs != 0) */ smp_rmb(); - desc = try_get_desc(&bp_desc); + desc = try_get_desc(); if (!desc) return 0; @@ -1440,7 +1441,7 @@ noinstr int poke_int3_handler(struct pt_ ret = 1; out_put: - put_desc(desc); + put_desc(); return ret; } @@ -1471,18 +1472,20 @@ static int tp_vec_nr; */ static void text_poke_bp_batch(struct text_poke_loc *tp, unsigned int nr_entries) { - struct bp_patching_desc desc = { - .vec = tp, - .nr_entries = nr_entries, - .refs = ATOMIC_INIT(1), - }; unsigned char int3 = INT3_INSN_OPCODE; unsigned int i; int do_sync; lockdep_assert_held(&text_mutex); - smp_store_release(&bp_desc, &desc); /* rcu_assign_pointer */ + bp_desc.vec = tp; + bp_desc.nr_entries = nr_entries; + + /* + * Corresponds to the implicit memory barrier in try_get_desc() to + * ensure reading a non-zero refcount provides up to date bp_desc data. + */ + atomic_set_release(&bp_desc.refs, 1); /* * Corresponding read barrier in int3 notifier for making sure the @@ -1570,12 +1573,10 @@ static void text_poke_bp_batch(struct te text_poke_sync(); /* - * Remove and synchronize_rcu(), except we have a very primitive - * refcount based completion. + * Remove and wait for refs to be zero. */ - WRITE_ONCE(bp_desc, NULL); /* RCU_INIT_POINTER */ - if (!atomic_dec_and_test(&desc.refs)) - atomic_cond_read_acquire(&desc.refs, !VAL); + if (!atomic_dec_and_test(&bp_desc.refs)) + atomic_cond_read_acquire(&bp_desc.refs, !VAL); } static void text_poke_loc_init(struct text_poke_loc *tp, void *addr,