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 D4599584968 for ; Fri, 11 Sep 2026 19:55:44 +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=1789156547; cv=none; b=nN0cyEZKdlv2FZh0pYRIaoeuhNCoUHCOGBSspOzrNlk9NGuUzSI5aCeFCZjga2cTBcOjyDRt7WOZJyPctaGt+4KPJ634QqVBY4uSiOhPFzi7EqOAxKqQYnlaNRInogZNS/USxkqnjUeLJvVTF+laeubkiR1k1rBtABT/uC5MUjY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789156547; c=relaxed/simple; bh=g4OZpMg5XWC7MWn2xv6tkxvB+dsfZRVonMp7SD3QvOg=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=mKpZ6NRWZ4kp84EZlnaFbcTCmYjbmgVisr6ctFypk54fjb5AvodRMUsLLVdipSpjjcjLy+9N5AJ/cXgqnGrarETlNPIQcMODHTYTvA+Qu80S08C8ss/13MTjusRc1l9IkaPUHcuMypHfUayP6qsSmjAUSnAZhnXS2l2wvult3uE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=zZ7hKWfb; 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="zZ7hKWfb" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B95E21F0089A; Fri, 11 Sep 2026 19:55:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1789156544; bh=fo/uBvAk6TEamrmWIoWfCxwgF2p9jQHcGIFCHUVvACo=; h=From:To:Cc:Subject:Date:Reply-To; b=zZ7hKWfbugJ0z8cJ+4kHgeJKGMo0eCwSkXeVn6i9qaVRHQUCuE+LoHpLlMc69yXTC KfwBfL8uKSK7NUXx+sRjHfLF/EDCggHFxnE35JmJaewpHkzjiqiFYFe4p9NGV4sLaK c7jjHglkDP87XVqcIZptvX4P/cQRPvJddBWZttec= From: Greg Kroah-Hartman To: linux-cve-announce@vger.kernel.org Cc: Greg Kroah-Hartman Subject: CVE-2026-89518: sched_ext: Fix this_rq() assumptions in dispatch kfuncs Date: Fri, 11 Sep 2026 21:43:27 +0200 Message-ID: <2026091114-CVE-2026-89518-d92e@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=3169; i=gregkh@linuxfoundation.org; h=from:subject:message-id; bh=YFdKIcQ0alBkr0SYrLgx0B4fAZvZptqHodAxP58DdCY=; b=owGbwMvMwCRo6H6F97bub03G02pJDFlLIqM6zC351APkU2cKHGy2zUrX5Mp7/tPocmH8Jrvjx 39zcG/siGVhEGRikBVTZPmyjefo/opDil6Gtqdh5rAygQxh4OIUgImc5GNYcKPFlEF3DfdCvZWn DNXOPD12K8z1O8OCmw0PLv993TBXY0OEyLb18ttFbn+TAQA= 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_ext: Fix this_rq() assumptions in dispatch kfuncs Under core scheduling, dispatch runs from within the core-wide pick and can target a sibling rq, so ops.dispatch() may execute on a CPU different from the dispatched rq's. Several kfunc paths assumed the two always coincide: - scx_dsq_move() decided whether an rq lock is held by testing this_rq()'s rq flags and lock-danced accordingly. A dispatch for a sibling took the unlocked-context branch and acquired the source rq lock on top of the already held dispatched rq lock which could deadlock. - scx_bpf_sub_dispatch() dispatched this_rq() with its stashed sub_dispatch_prev, which is NULL when dispatching for a sibling. - finish_dispatch(), scx_bpf_dsq_reenq() and scx_bpf_dsq_nr_queued() resolved SCX_DSQ_LOCAL to this CPU's local DSQ rather than the dispatched rq's. The latter two are callable from other rq-locked operations too, where SCX_DSQ_LOCAL now likewise resolves to the op's rq. This changes behavior also without core scheduling, e.g. for ops.enqueue() running a remote wakeup on the waking CPU, and is intended: which CPU happens to execute an operation is incidental, the op's rq is what it is operating on, and the resolution now matches the insert side where SCX_DSQ_LOCAL dispatches land on the task's rq. Use the rq tracked by scx_locked_rq(), which is set to the dispatched rq around ops invocations and NULL in unlocked contexts. The Linux kernel CVE team has assigned CVE-2026-89518 to this issue. Affected and fixed versions =========================== Issue introduced in 6.19 with commit 4c95380701f58b8112f0b891de8d160e4199e19d and fixed in 7.2.4 with commit 6d1890d3c6137ab523799765ae2de62cc05f116d Issue introduced in 6.19 with commit 4c95380701f58b8112f0b891de8d160e4199e19d and fixed in 7.3-rc1 with commit 3dd52416e44a70bc993adb96d2e0d71b9ea21359 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-89518 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/ext/ext.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/6d1890d3c6137ab523799765ae2de62cc05f116d https://git.kernel.org/stable/c/3dd52416e44a70bc993adb96d2e0d71b9ea21359