From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CD6DC581228 for ; Fri, 11 Sep 2026 19:55:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789156567; cv=none; b=WYi6HdnRGslvsoXaNbGklHLYRzxNwPzozbgr90TauYWWb3Uf+lyfhUtzSjQJ+uRGUIpOVhVHwIiehannj1dphBH0xCZo4l2R4vnytD8lk05M6zb1kShp3zUGWtyuYbG1NZMFRFi4KcDWmpULsdR6ds0ldO6vHymWKpox6WA23j0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789156567; c=relaxed/simple; bh=tg+hQnvnMRCZ4k+uWKNud51YgwQoTvvoGzR9m+SJxCI=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=dki65X0OqUGhZwVmFpJAgUdpfi8xoreZ2/UNGbQ//pjw8mwivDqoLXuB7VzEq8crCLi677WZezAqmYHjkuY41NztOAANO0ejNCGeS8IRKBMEKqPTWjDdLOhVh2KMgDZU3abyCV/szF+Hs1m0euHa1mzE48gmXFdJhsaPlsz/AxE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=xOI4TLdK; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="xOI4TLdK" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A0E0E1F00898; Fri, 11 Sep 2026 19:55:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1789156553; bh=DZgzu7dEZ3eQzuBIC9q7tyLq/W+TbysutGcqvY/4fYs=; h=From:To:Cc:Subject:Date:Reply-To; b=xOI4TLdKIuzW/4SP6Yc2SpWEj2lD7kDVbZ9g7pIUo4qQmdZY6sJR0Ze16kwZMI0Ts 3mcbzeeRG2th+Ir97SZuunfX46Urm/yj/N1QSWUMXFoUW5vl8PqVDo+rnq4LMTNbny aoVTOfAp7722c3s4V1AkDlOTtL7My1yh3IqJUTYc= From: Greg Kroah-Hartman To: linux-cve-announce@vger.kernel.org Cc: Greg Kroah-Hartman Subject: CVE-2026-89521: sched/core: Handle pick_task() releasing the rq lock Date: Fri, 11 Sep 2026 21:43:30 +0200 Message-ID: <2026091114-CVE-2026-89521-4a57@gregkh> X-Mailer: git-send-email 2.55.0 Reply-To: , Precedence: bulk X-Mailing-List: linux-cve-announce@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=2969; i=gregkh@linuxfoundation.org; h=from:subject:message-id; bh=rew/NoxDj9eCcDFBJMv0DPRPYSi7GgNBZUcy+vd7V0g=; b=owGbwMvMwCRo6H6F97bub03G02pJDFlLIqOepD7eKC5/fr/dcS7bvsX3lq/031UWsP2CdzX3p +OxFUu+dsSyMAgyMciKKbJ82cZzdH/FIUUvQ9vTMHNYmUCGMHBxCsBNPsEwV9YuhKV/5/qi106i Nvba7tk/bnhFMcz3/6NSYlW9+aFQ8/L6/sK0KkHGr5cB X-Developer-Key: i=gregkh@linuxfoundation.org; a=openpgp; fpr=F4B60CC5BF78C2214A313DCB3147D40DDB2DFB29 Content-Transfer-Encoding: 8bit From: Greg Kroah-Hartman Description =========== In the Linux kernel, the following vulnerability has been resolved: sched/core: Handle pick_task() releasing the rq lock Core scheduling's pick_next_task() breaks when a ->pick_task() implementation can release the rq lock. The selection state derived on entry is only valid while the lock is held continuously. Once a pick can drop the lock, an interleaving selection can invalidate all of it: the single-CPU fast path can commit an uncookied pick although the core went cookied during the release, and forceidle committed by the interleaving selection skews the restarted pass's accounting. Fix it by restarting the whole selection when a pick returns RETRY_TASK after releasing the lock: a single restart point above the state derivation replaces the per-loop restart labels, so a retry picks up state committed by interleaving selections and accounts and resets forceidle like a fresh selection would. need_sync and fi_before latch across retries. Clock validity can't be re-derived - there is no program-ordered way to tell whether the own and core rq clocks are still updated after the lock was released, as other lockers' pin cycles may or may not have invalidated them. When restarting, clear core_clock_updated so that the sibling loop re-updates the core rq, and update the own rq clock if invalidated. The Linux kernel CVE team has assigned CVE-2026-89521 to this issue. Affected and fixed versions =========================== Issue introduced in 6.19 with commit 4c95380701f58b8112f0b891de8d160e4199e19d and fixed in 7.2.4 with commit 88ed5a66467ca2a5148b9997af9c71d8c43060ad Issue introduced in 6.19 with commit 4c95380701f58b8112f0b891de8d160e4199e19d and fixed in 7.3-rc1 with commit c10b216a072ff5c57bc880a05f87eb519aecc529 Please see https://www.kernel.org for a full list of currently supported kernel versions by the kernel community. Unaffected versions might change over time as fixes are backported to older supported kernel versions. The official CVE entry at https://cve.org/CVERecord/?id=CVE-2026-89521 will be updated if fixes are backported, please check that for the most up to date information about this issue. Affected files ============== The file(s) affected by this issue are: kernel/sched/core.c Mitigation ========== The Linux kernel CVE team recommends that you update to the latest stable kernel version for this, and many other bugfixes. Individual changes are never tested alone, but rather are part of a larger kernel release. Cherry-picking individual commits is not recommended or supported by the Linux kernel community at all. If however, updating to the latest release is impossible, the individual changes to resolve this issue can be found at these commits: https://git.kernel.org/stable/c/88ed5a66467ca2a5148b9997af9c71d8c43060ad https://git.kernel.org/stable/c/c10b216a072ff5c57bc880a05f87eb519aecc529