CVE-2022-48845 in Linux
Summary
by MITRE • 07/16/2024
In the Linux kernel, the following vulnerability has been resolved:
MIPS: smp: fill in sibling and core maps earlier
After enabling CONFIG_SCHED_CORE (landed during 5.14 cycle), 2-core 2-thread-per-core interAptiv (CPS-driven) started emitting the following:
[ 0.025698] CPU1 revision is: 0001a120 (MIPS interAptiv (multi))
[ 0.048183] ------------[ cut here ]------------
[ 0.048187] WARNING: CPU: 1 PID: 0 at kernel/sched/core.c:6025 sched_core_cpu_starting+0x198/0x240
[ 0.048220] Modules linked in:
[ 0.048233] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.17.0-rc3+ #35 b7b319f24073fd9a3c2aa7ad15fb7993eec0b26f
[ 0.048247] Stack : 817f0000 00000004 327804c8 810eb050 00000000 00000004 00000000 c314fdd1
[ 0.048278] 830cbd64 819c0000 81800000 817f0000 83070bf4 00000001 830cbd08 00000000
[ 0.048307] 00000000 00000000 815fcbc4 00000000 00000000 00000000 00000000 00000000
[ 0.048334] 00000000 00000000 00000000 00000000 817f0000 00000000 00000000 817f6f34
[ 0.048361] 817f0000 818a3c00 817f0000 00000004 00000000 00000000 4dc33260 0018c933
[ 0.048389] ...
[ 0.048396] Call Trace:
[ 0.048399] [] show_stack+0x3c/0x140
[ 0.048424] [] dump_stack_lvl+0x60/0x80
[ 0.048440] [] __warn+0xc0/0xf4
[ 0.048454] [] warn_slowpath_fmt+0x64/0x10c
[ 0.048467] [] sched_core_cpu_starting+0x198/0x240
[ 0.048483] [] sched_cpu_starting+0x14/0x80
[ 0.048497] [] cpuhp_invoke_callback_range+0x78/0x140
[ 0.048510] [] notify_cpu_starting+0x94/0x140
[ 0.048523] [] start_secondary+0xbc/0x280
[ 0.048539]
[ 0.048543] ---[ end trace 0000000000000000 ]---
[ 0.048636] Synchronize counters for CPU 1: done.
...for each but CPU 0/boot. Basic debug printks right before the mentioned line say:
[ 0.048170] CPU: 1, smt_mask:
So smt_mask, which is sibling mask obviously, is empty when entering the function. This is critical, as sched_core_cpu_starting() calculates core-scheduling parameters only once per CPU start, and it's crucial to have all the parameters filled in at that moment (at least it uses cpu_smt_mask() which in fact is `&cpu_sibling_map[cpu]` on
MIPS).
A bit of debugging led me to that set_cpu_sibling_map() performing the actual map calculation, was being invocated after notify_cpu_start(), and exactly the latter function starts CPU HP callback round (sched_core_cpu_starting() is basically a CPU HP callback). While the flow is same on ARM64 (maps after the notifier, although before calling set_cpu_online()), x86 started calculating sibling maps earlier than starting the CPU HP callbacks in Linux 4.14 (see [0] for the reference). Neither me nor my brief tests couldn't find
any potential caveats in calculating the maps right after performing delay calibration, but the WARN splat is now gone. The very same debug prints now yield exactly what I expected from them:
[ 0.048433] CPU: 1, smt_mask: 0-1
[0] https://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git/commit/?id=76ce7cfe35ef
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 08/10/2025
The vulnerability described in CVE-2022-48845 affects the Linux kernel's handling of symmetric multiprocessing scheduling on MIPS architecture processors. This issue manifests when the CONFIG_SCHED_CORE configuration option is enabled, which introduces core scheduling functionality that allows multiple logical processors to be grouped together for scheduling purposes. The problem occurs specifically on systems with 2-core configurations where each core has 2 threads, such as the interAptiv processor with CPS-driven architecture. The vulnerability stems from an improper ordering of initialization steps during CPU bring-up, causing critical scheduling data structures to remain uninitialized when needed.
The technical flaw involves the timing of when sibling and core maps are populated in the kernel's scheduler subsystem. During the CPU startup process, the function sched_core_cpu_starting() is invoked as part of the CPU hotplug callback mechanism, but at this point the cpu_sibling_map data structures have not yet been initialized. This results in empty sibling masks being passed to scheduling functions, causing kernel warnings and potential system instability. The issue is particularly critical because the core scheduling parameters are calculated only once per CPU start, making it essential that all necessary data structures are properly populated before this calculation occurs. The cpu_smt_mask() function, which is crucial for determining thread-level scheduling relationships, relies on the cpu_sibling_map array, which in this case remains uninitialized.
The operational impact of this vulnerability extends beyond simple kernel warnings to potentially destabilize systems running on MIPS architecture with core scheduling enabled. When the kernel attempts to process CPU startup events, it encounters NULL or empty sibling mask values, triggering the warning message and stack trace that indicates the failure to properly initialize CPU topology information. This can lead to improper scheduling decisions, reduced system performance, and in some cases, system crashes or hangs during multi-core CPU initialization. The vulnerability specifically affects systems where CONFIG_SCHED_CORE is enabled, which became available starting with kernel version 5.14, making it a significant concern for modern Linux systems utilizing MIPS processors with hyperthreading capabilities.
The mitigation strategy for this vulnerability involves ensuring that sibling and core map initialization occurs before CPU hotplug callbacks are invoked. The fix implemented in the kernel addresses the ordering issue by moving the set_cpu_sibling_map() function call earlier in the CPU initialization sequence, before the notify_cpu_start() function which triggers the hotplug callbacks. This approach aligns with the methodology used successfully on other architectures like x86, which has been implementing early sibling map calculation since kernel version 4.14. The solution ensures that all CPU topology information is available before any scheduling decisions are made, preventing the race condition that led to the kernel warnings. This fix is consistent with best practices for kernel initialization ordering and follows established patterns from the Linux kernel development community for handling CPU topology data structures.
This vulnerability relates to CWE-362, which describes a race condition in concurrent programming, and can be mapped to ATT&CK technique T1059.003 for kernel-level privilege escalation through system call manipulation. The fix demonstrates proper initialization sequence management and adheres to the principle of least privilege by ensuring that all necessary system resources are properly configured before critical operations begin. The resolution maintains system stability while preserving the intended functionality of core scheduling on MIPS architecture processors, aligning with security best practices for kernel development and vulnerability remediation.