CVE-2022-48845

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> MIPS: smp: fill in sibling and core maps earlier<br /> <br /> After enabling CONFIG_SCHED_CORE (landed during 5.14 cycle),<br /> 2-core 2-thread-per-core interAptiv (CPS-driven) started emitting<br /> the following:<br /> <br /> [ 0.025698] CPU1 revision is: 0001a120 (MIPS interAptiv (multi))<br /> [ 0.048183] ------------[ cut here ]------------<br /> [ 0.048187] WARNING: CPU: 1 PID: 0 at kernel/sched/core.c:6025 sched_core_cpu_starting+0x198/0x240<br /> [ 0.048220] Modules linked in:<br /> [ 0.048233] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.17.0-rc3+ #35 b7b319f24073fd9a3c2aa7ad15fb7993eec0b26f<br /> [ 0.048247] Stack : 817f0000 00000004 327804c8 810eb050 00000000 00000004 00000000 c314fdd1<br /> [ 0.048278] 830cbd64 819c0000 81800000 817f0000 83070bf4 00000001 830cbd08 00000000<br /> [ 0.048307] 00000000 00000000 815fcbc4 00000000 00000000 00000000 00000000 00000000<br /> [ 0.048334] 00000000 00000000 00000000 00000000 817f0000 00000000 00000000 817f6f34<br /> [ 0.048361] 817f0000 818a3c00 817f0000 00000004 00000000 00000000 4dc33260 0018c933<br /> [ 0.048389] ...<br /> [ 0.048396] Call Trace:<br /> [ 0.048399] [] show_stack+0x3c/0x140<br /> [ 0.048424] [] dump_stack_lvl+0x60/0x80<br /> [ 0.048440] [] __warn+0xc0/0xf4<br /> [ 0.048454] [] warn_slowpath_fmt+0x64/0x10c<br /> [ 0.048467] [] sched_core_cpu_starting+0x198/0x240<br /> [ 0.048483] [] sched_cpu_starting+0x14/0x80<br /> [ 0.048497] [] cpuhp_invoke_callback_range+0x78/0x140<br /> [ 0.048510] [] notify_cpu_starting+0x94/0x140<br /> [ 0.048523] [] start_secondary+0xbc/0x280<br /> [ 0.048539]<br /> [ 0.048543] ---[ end trace 0000000000000000 ]---<br /> [ 0.048636] Synchronize counters for CPU 1: done.<br /> <br /> ...for each but CPU 0/boot.<br /> Basic debug printks right before the mentioned line say:<br /> <br /> [ 0.048170] CPU: 1, smt_mask:<br /> <br /> So smt_mask, which is sibling mask obviously, is empty when entering<br /> the function.<br /> This is critical, as sched_core_cpu_starting() calculates<br /> core-scheduling parameters only once per CPU start, and it&amp;#39;s crucial<br /> to have all the parameters filled in at that moment (at least it<br /> uses cpu_smt_mask() which in fact is `&amp;cpu_sibling_map[cpu]` on<br /> MIPS).<br /> <br /> A bit of debugging led me to that set_cpu_sibling_map() performing<br /> the actual map calculation, was being invocated after<br /> notify_cpu_start(), and exactly the latter function starts CPU HP<br /> callback round (sched_core_cpu_starting() is basically a CPU HP<br /> callback).<br /> While the flow is same on ARM64 (maps after the notifier, although<br /> before calling set_cpu_online()), x86 started calculating sibling<br /> maps earlier than starting the CPU HP callbacks in Linux 4.14 (see<br /> [0] for the reference). Neither me nor my brief tests couldn&amp;#39;t find<br /> any potential caveats in calculating the maps right after performing<br /> delay calibration, but the WARN splat is now gone.<br /> The very same debug prints now yield exactly what I expected from<br /> them:<br /> <br /> [ 0.048433] CPU: 1, smt_mask: 0-1<br /> <br /> [0] https://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git/commit/?id=76ce7cfe35ef