| From bippy-5f407fcff5a0 Mon Sep 17 00:00:00 2001 |
| From: Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
| To: <linux-cve-announce@vger.kernel.org> |
| Reply-to: <cve@kernel.org>, <linux-kernel@vger.kernel.org> |
| Subject: CVE-2024-42245: Revert "sched/fair: Make sure to try to detach at least one movable task" |
| |
| Description |
| =========== |
| |
| In the Linux kernel, the following vulnerability has been resolved: |
| |
| Revert "sched/fair: Make sure to try to detach at least one movable task" |
| |
| This reverts commit b0defa7ae03ecf91b8bfd10ede430cff12fcbd06. |
| |
| b0defa7ae03ec changed the load balancing logic to ignore env.max_loop if |
| all tasks examined to that point were pinned. The goal of the patch was |
| to make it more likely to be able to detach a task buried in a long list |
| of pinned tasks. However, this has the unfortunate side effect of |
| creating an O(n) iteration in detach_tasks(), as we now must fully |
| iterate every task on a cpu if all or most are pinned. Since this load |
| balance code is done with rq lock held, and often in softirq context, it |
| is very easy to trigger hard lockups. We observed such hard lockups with |
| a user who affined O(10k) threads to a single cpu. |
| |
| When I discussed this with Vincent he initially suggested that we keep |
| the limit on the number of tasks to detach, but increase the number of |
| tasks we can search. However, after some back and forth on the mailing |
| list, he recommended we instead revert the original patch, as it seems |
| likely no one was actually getting hit by the original issue. |
| |
| The Linux kernel CVE team has assigned CVE-2024-42245 to this issue. |
| |
| |
| Affected and fixed versions |
| =========================== |
| |
| Issue introduced in 6.1 with commit b0defa7ae03ecf91b8bfd10ede430cff12fcbd06 and fixed in 6.1.100 with commit d467194018dd536fe6c65a2fd3aedfcdb1424903 |
| Issue introduced in 6.1 with commit b0defa7ae03ecf91b8bfd10ede430cff12fcbd06 and fixed in 6.6.41 with commit 1e116c18e32b035a2d1bd460800072c8bf96bc44 |
| Issue introduced in 6.1 with commit b0defa7ae03ecf91b8bfd10ede430cff12fcbd06 and fixed in 6.9.10 with commit 0fa6dcbfa2e2b97c1e6febbea561badf0931a38b |
| Issue introduced in 6.1 with commit b0defa7ae03ecf91b8bfd10ede430cff12fcbd06 and fixed in 6.10 with commit 2feab2492deb2f14f9675dd6388e9e2bf669c27a |
| |
| 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-2024-42245 |
| 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/fair.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/d467194018dd536fe6c65a2fd3aedfcdb1424903 |
| https://git.kernel.org/stable/c/1e116c18e32b035a2d1bd460800072c8bf96bc44 |
| https://git.kernel.org/stable/c/0fa6dcbfa2e2b97c1e6febbea561badf0931a38b |
| https://git.kernel.org/stable/c/2feab2492deb2f14f9675dd6388e9e2bf669c27a |
