Received: by 2002:a05:6358:16cc:b0:ea:6187:17c9 with SMTP id r12csp6000123rwl; Mon, 9 Jan 2023 02:53:40 -0800 (PST) X-Google-Smtp-Source: AMrXdXve3ZYVW0vJdPfTGrYpqkJl/cpUnIsFGaDUf3XvB+vbgcHduFZ4aha9yQ+K1aUQbY6RNnv+ X-Received: by 2002:a17:907:bb8b:b0:84d:1f41:1177 with SMTP id xo11-20020a170907bb8b00b0084d1f411177mr9395874ejc.68.1673261620346; Mon, 09 Jan 2023 02:53:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1673261620; cv=none; d=google.com; s=arc-20160816; b=sY87YLOemQu9vxH/jmH6zcuVKDJESETg1l8NgsLb4LYBOHsWMFVy3HEP/ocMe3nINg HZr3huQymTKVt9HUfoqxFwdSfL7e4YoWBbuBszAprcWkvFq3J2zOd8BlAQ5G2MosINmc BgJwwKvauhdrrQCTAsVbVH8Fl58k+mNp0OxciFFKV+UK3dDkSCjF8VfC+o7ZypframmQ uNBqqUT4Q+UIngIiMh3Gk5NIfM8m2HoL3bljLRTcBvPsRSc4a8j9O2kS371SdpNi9HiP cTJ8O1xqj38VyzEEevlmdRkwDmSWq1KG94mDoaHismWWzI6u5lI8G/f6oudDh1n8J57i nNvg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:robot-unsubscribe :robot-id:message-id:mime-version:references:in-reply-to:cc:subject :to:reply-to:sender:from:dkim-signature:dkim-signature:date; bh=gGLD8+z5v/LG8xvOUesGcsFZx/qPDMoUmcfWijv42DU=; b=TvVEY6yoia8vlcuHw/ieSj+L5qiZy90DzRnKgXKj8FMoBXvpM3OE69el4ql+YZmhyC d97pvul3VwHG1PzBpDZIBLpObRm5XFY12bDer94gkTmCjRJ4jl/vCc3Jtk5XktJvE5Wk r8v7Si3VAZQ4zUFrklwWR/DSfL4nb0AQvAAQCJVAcPevKmiSnVHK+5q9aXY13G9PbzsM AF/uYPwGvrTYa7Wc7T/1+5bDGV8U8mL2sxcOKQeUTAkkiW5i1lD6Pe98kyToZ9yv3qZF 0hQQgY31m7UJC/2z7Wag8yIJdZ/OSGP1ROHDKt33Y6+X8Po2Ra/WSsOba9AxncMGH7yr WyBA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=2JKuqP3g; dkim=neutral (no key) header.i=@linutronix.de header.s=2020e header.b=UE5bLrXg; 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=QUARANTINE dis=NONE) header.from=linutronix.de Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id sa41-20020a1709076d2900b0084cb98e14e2si8888643ejc.621.2023.01.09.02.53.27; Mon, 09 Jan 2023 02:53:40 -0800 (PST) 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=@linutronix.de header.s=2020 header.b=2JKuqP3g; dkim=neutral (no key) header.i=@linutronix.de header.s=2020e header.b=UE5bLrXg; 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=QUARANTINE dis=NONE) header.from=linutronix.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236489AbjAIKqX (ORCPT + 53 others); Mon, 9 Jan 2023 05:46:23 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54526 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233624AbjAIKpx (ORCPT ); Mon, 9 Jan 2023 05:45:53 -0500 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 23F671154; Mon, 9 Jan 2023 02:45:52 -0800 (PST) Date: Mon, 09 Jan 2023 10:45:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1673261150; h=from:from:sender:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=gGLD8+z5v/LG8xvOUesGcsFZx/qPDMoUmcfWijv42DU=; b=2JKuqP3gSsoSTh52HB1d7883yQG/teisK4lXdRQ73bUJvWY4std7proEXaTcunN8j8Ahsj FgvYWXQrnIOo2XlCcOqsbeTAmKAuMMOG6VCpKkmnUnloqq5aT+BrnorsQLUBR8XHVZHu18 XAvEJD58R7lS/bm2wlYybpuM77Zxr9BVS8V3Dq8SvPghONdb1aUcSgVUcLZx8G11WmU50f Tvao6RjakVeH+ZJUvaAc2qpLAmdwcDdNn81Ffbo6kO/IDX45ZkRcpuD5rOsKz09FlnwSa1 8qLX0ZeO5WSvmBYon+Ll7AKERPcfaTErooI2zq7UntXxpYEGGExGqcqMcQORHw== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1673261150; h=from:from:sender:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=gGLD8+z5v/LG8xvOUesGcsFZx/qPDMoUmcfWijv42DU=; b=UE5bLrXghdLmn3z6E5Ex3nFlHVpElfHlvvtxUzt4Rntli/TNPw1pC8Je5IXDW7AM+sfqd2 jLl+D13xrQYEI0CQ== From: "tip-bot2 for Waiman Long" Sender: tip-bot2@linutronix.de Reply-to: linux-kernel@vger.kernel.org To: linux-tip-commits@vger.kernel.org Subject: [tip: sched/urgent] sched/core: Fix use-after-free bug in dup_user_cpus_ptr() Cc: wangbiao3@xiaomi.com, Waiman Long , Ingo Molnar , Peter Zijlstra , stable@vger.kernel.org, x86@kernel.org, linux-kernel@vger.kernel.org In-Reply-To: <20221231041120.440785-2-longman@redhat.com> References: <20221231041120.440785-2-longman@redhat.com> MIME-Version: 1.0 Message-ID: <167326115033.4906.12022600051582690009.tip-bot2@tip-bot2> Robot-ID: Robot-Unsubscribe: Contact to get blacklisted from these emails Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,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 The following commit has been merged into the sched/urgent branch of tip: Commit-ID: 87ca4f9efbd7cc649ff43b87970888f2812945b8 Gitweb: https://git.kernel.org/tip/87ca4f9efbd7cc649ff43b87970888f2812= 945b8 Author: Waiman Long AuthorDate: Fri, 30 Dec 2022 23:11:19 -05:00 Committer: Ingo Molnar CommitterDate: Mon, 09 Jan 2023 11:43:07 +01:00 sched/core: Fix use-after-free bug in dup_user_cpus_ptr() Since commit 07ec77a1d4e8 ("sched: Allow task CPU affinity to be restricted on asymmetric systems"), the setting and clearing of user_cpus_ptr are done under pi_lock for arm64 architecture. However, dup_user_cpus_ptr() accesses user_cpus_ptr without any lock protection. Since sched_setaffinity() can be invoked from another process, the process being modified may be undergoing fork() at the same time. When racing with the clearing of user_cpus_ptr in __set_cpus_allowed_ptr_locked(), it can lead to user-after-free and possibly double-free in arm64 kernel. Commit 8f9ea86fdf99 ("sched: Always preserve the user requested cpumask") fixes this problem as user_cpus_ptr, once set, will never be cleared in a task's lifetime. However, this bug was re-introduced in commit 851a723e45d1 ("sched: Always clear user_cpus_ptr in do_set_cpus_allowed()") which allows the clearing of user_cpus_ptr in do_set_cpus_allowed(). This time, it will affect all arches. Fix this bug by always clearing the user_cpus_ptr of the newly cloned/forked task before the copying process starts and check the user_cpus_ptr state of the source task under pi_lock. Note to stable, this patch won't be applicable to stable releases. Just copy the new dup_user_cpus_ptr() function over. Fixes: 07ec77a1d4e8 ("sched: Allow task CPU affinity to be restricted on asym= metric systems") Fixes: 851a723e45d1 ("sched: Always clear user_cpus_ptr in do_set_cpus_allowe= d()") Reported-by: David Wang =E7=8E=8B=E6=A0=87 Signed-off-by: Waiman Long Signed-off-by: Ingo Molnar Reviewed-by: Peter Zijlstra Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20221231041120.440785-2-longman@redhat.com --- kernel/sched/core.c | 34 +++++++++++++++++++++++++++++----- 1 file changed, 29 insertions(+), 5 deletions(-) diff --git a/kernel/sched/core.c b/kernel/sched/core.c index 965d813..f9f6e54 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -2612,19 +2612,43 @@ void do_set_cpus_allowed(struct task_struct *p, const= struct cpumask *new_mask) int dup_user_cpus_ptr(struct task_struct *dst, struct task_struct *src, int node) { + cpumask_t *user_mask; unsigned long flags; =20 - if (!src->user_cpus_ptr) + /* + * Always clear dst->user_cpus_ptr first as their user_cpus_ptr's + * may differ by now due to racing. + */ + dst->user_cpus_ptr =3D NULL; + + /* + * This check is racy and losing the race is a valid situation. + * It is not worth the extra overhead of taking the pi_lock on + * every fork/clone. + */ + if (data_race(!src->user_cpus_ptr)) return 0; =20 - dst->user_cpus_ptr =3D kmalloc_node(cpumask_size(), GFP_KERNEL, node); - if (!dst->user_cpus_ptr) + user_mask =3D kmalloc_node(cpumask_size(), GFP_KERNEL, node); + if (!user_mask) return -ENOMEM; =20 - /* Use pi_lock to protect content of user_cpus_ptr */ + /* + * Use pi_lock to protect content of user_cpus_ptr + * + * Though unlikely, user_cpus_ptr can be reset to NULL by a concurrent + * do_set_cpus_allowed(). + */ raw_spin_lock_irqsave(&src->pi_lock, flags); - cpumask_copy(dst->user_cpus_ptr, src->user_cpus_ptr); + if (src->user_cpus_ptr) { + swap(dst->user_cpus_ptr, user_mask); + cpumask_copy(dst->user_cpus_ptr, src->user_cpus_ptr); + } raw_spin_unlock_irqrestore(&src->pi_lock, flags); + + if (unlikely(user_mask)) + kfree(user_mask); + return 0; } =20