| 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-2022-49090: arch/arm64: Fix topology initialization for core scheduling |
| |
| Description |
| =========== |
| |
| In the Linux kernel, the following vulnerability has been resolved: |
| |
| arch/arm64: Fix topology initialization for core scheduling |
| |
| Arm64 systems rely on store_cpu_topology() to call update_siblings_masks() |
| to transfer the toplogy to the various cpu masks. This needs to be done |
| before the call to notify_cpu_starting() which tells the scheduler about |
| each cpu found, otherwise the core scheduling data structures are setup |
| in a way that does not match the actual topology. |
| |
| With smt_mask not setup correctly we bail on `cpumask_weight(smt_mask) == 1` |
| for !leaders in: |
| |
| notify_cpu_starting() |
| cpuhp_invoke_callback_range() |
| sched_cpu_starting() |
| sched_core_cpu_starting() |
| |
| which leads to rq->core not being correctly set for !leader-rq's. |
| |
| Without this change stress-ng (which enables core scheduling in its prctl |
| tests in newer versions -- i.e. with PR_SCHED_CORE support) causes a warning |
| and then a crash (trimmed for legibility): |
| |
| [ 1853.805168] ------------[ cut here ]------------ |
| [ 1853.809784] task_rq(b)->core != rq->core |
| [ 1853.809792] WARNING: CPU: 117 PID: 0 at kernel/sched/fair.c:11102 cfs_prio_less+0x1b4/0x1c4 |
| ... |
| [ 1854.015210] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 |
| ... |
| [ 1854.231256] Call trace: |
| [ 1854.233689] pick_next_task+0x3dc/0x81c |
| [ 1854.237512] __schedule+0x10c/0x4cc |
| [ 1854.240988] schedule_idle+0x34/0x54 |
| |
| The Linux kernel CVE team has assigned CVE-2022-49090 to this issue. |
| |
| |
| Affected and fixed versions |
| =========================== |
| |
| Issue introduced in 5.14 with commit 9edeaea1bc452372718837ed2ba775811baf1ba1 and fixed in 5.15.34 with commit 87f5d66daa5f457449bb95d6b8d18bb7596aa627 |
| Issue introduced in 5.14 with commit 9edeaea1bc452372718837ed2ba775811baf1ba1 and fixed in 5.16.20 with commit 790c1567582bda8f1153015436e3330a7c6eb278 |
| Issue introduced in 5.14 with commit 9edeaea1bc452372718837ed2ba775811baf1ba1 and fixed in 5.17.3 with commit c78a1b2d0bff678570c8dc9f14035606f5e5257d |
| Issue introduced in 5.14 with commit 9edeaea1bc452372718837ed2ba775811baf1ba1 and fixed in 5.18 with commit 5524cbb1bfcdff0cad0aaa9f94e6092002a07259 |
| |
| 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-2022-49090 |
| 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: |
| arch/arm64/kernel/smp.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/87f5d66daa5f457449bb95d6b8d18bb7596aa627 |
| https://git.kernel.org/stable/c/790c1567582bda8f1153015436e3330a7c6eb278 |
| https://git.kernel.org/stable/c/c78a1b2d0bff678570c8dc9f14035606f5e5257d |
| https://git.kernel.org/stable/c/5524cbb1bfcdff0cad0aaa9f94e6092002a07259 |