CVE-2022-48845

一、漏洞信息
 漏洞编号：[CVE-2022-48845](https://nvd.nist.gov/vuln/detail/CVE-2022-48845)
 漏洞归属组件：[kernel](https://gitee.com/src-openeuler/kernel)
 漏洞归属的版本：4.19.140,4.19.194,4.19.90,5.10.0,6.1.0,6.1.14,6.1.19,6.1.5,6.1.6,6.1.8,6.4.0,6.6.0
 CVSS V3.0分值：
  BaseScore：5.5 Medium
  Vector：CVSS：3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
 漏洞简述：
  In the Linux kernel, the following vulnerability has been resolved:MIPS: smp: fill in sibling and core maps earlierAfter enabling CONFIG_SCHED_CORE (landed during 5.14 cycle),2-core 2-thread-per-core interAptiv (CPS-driven) started emittingthe 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] [<8105a7bc>] show_stack+0x3c/0x140[    0.048424] [<8131c2a0>] dump_stack_lvl+0x60/0x80[    0.048440] [<8108b5c0>] __warn+0xc0/0xf4[    0.048454] [<8108b658>] warn_slowpath_fmt+0x64/0x10c[    0.048467] [<810bd418>] sched_core_cpu_starting+0x198/0x240[    0.048483] [<810c6514>] sched_cpu_starting+0x14/0x80[    0.048497] [<8108c0f8>] cpuhp_invoke_callback_range+0x78/0x140[    0.048510] [<8108d914>] notify_cpu_starting+0x94/0x140[    0.048523] [<8106593c>] 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 enteringthe function.This is critical, as sched_core_cpu_starting() calculatescore-scheduling parameters only once per CPU start, and it s crucialto have all the parameters filled in at that moment (at least ituses cpu_smt_mask() which in fact is `&cpu_sibling_map[cpu]` onMIPS).A bit of debugging led me to that set_cpu_sibling_map() performingthe actual map calculation, was being invocated afternotify_cpu_start(), and exactly the latter function starts CPU HPcallback round (sched_core_cpu_starting() is basically a CPU HPcallback).While the flow is same on ARM64 (maps after the notifier, althoughbefore calling set_cpu_online()), x86 started calculating siblingmaps earlier than starting the CPU HP callbacks in Linux 4.14 (see[0] for the reference). Neither me nor my brief tests couldn t findany potential caveats in calculating the maps right after performingdelay calibration, but the WARN splat is now gone.The very same debug prints now yield exactly what I expected fromthem:[    0.048433] CPU: 1, smt_mask: 0-1[0] https://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git/commit/?id=76ce7cfe35ef
 漏洞公开时间：2024-07-16 21:15:11
 漏洞创建时间：2024-07-17 02:52:48
 漏洞详情参考链接：
  https://nvd.nist.gov/vuln/detail/CVE-2022-48845
<details>
<summary>更多参考(点击展开)</summary>

| 参考来源 | 参考链接 | 来源链接 |
| ------- | -------- | -------- |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/32813321f18d5432cec1b1a6ecc964f9ea26d565 |  |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/56eaacb8137ba2071ce48d4e3d91979270e139a7 |  |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/7315f8538db009605ffba00370678142ef00ac98 |  |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/94647aec80d03d6914aa664b7b8e103cd9d63239 |  |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/be538b764a46be1d0700fd3b6e82fb76bd17f13a |  |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/c2420bc3333111184cdcb112282d13afe1338dd7 |  |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/e8ad9ecc406974deb5e7c070f51cc1d09d21dc4b |  |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/f2703def339c793674010cc9f01bfe4980231808 |  |
| suse_bugzilla | http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-48845 | https://bugzilla.suse.com/show_bug.cgi?id=1228070 |
| suse_bugzilla | https://www.cve.org/CVERecord?id=CVE-2022-48845 | https://bugzilla.suse.com/show_bug.cgi?id=1228070 |
| suse_bugzilla | https://git.kernel.org/stable/c/32813321f18d5432cec1b1a6ecc964f9ea26d565 | https://bugzilla.suse.com/show_bug.cgi?id=1228070 |
| suse_bugzilla | https://git.kernel.org/stable/c/56eaacb8137ba2071ce48d4e3d91979270e139a7 | https://bugzilla.suse.com/show_bug.cgi?id=1228070 |
| suse_bugzilla | https://git.kernel.org/stable/c/7315f8538db009605ffba00370678142ef00ac98 | https://bugzilla.suse.com/show_bug.cgi?id=1228070 |
| suse_bugzilla | https://git.kernel.org/stable/c/94647aec80d03d6914aa664b7b8e103cd9d63239 | https://bugzilla.suse.com/show_bug.cgi?id=1228070 |
| suse_bugzilla | https://git.kernel.org/stable/c/be538b764a46be1d0700fd3b6e82fb76bd17f13a | https://bugzilla.suse.com/show_bug.cgi?id=1228070 |
| suse_bugzilla | https://git.kernel.org/stable/c/c2420bc3333111184cdcb112282d13afe1338dd7 | https://bugzilla.suse.com/show_bug.cgi?id=1228070 |
| suse_bugzilla | https://git.kernel.org/stable/c/e8ad9ecc406974deb5e7c070f51cc1d09d21dc4b | https://bugzilla.suse.com/show_bug.cgi?id=1228070 |
| suse_bugzilla | https://git.kernel.org/stable/c/f2703def339c793674010cc9f01bfe4980231808 | https://bugzilla.suse.com/show_bug.cgi?id=1228070 |
| suse_bugzilla | https://git.kernel.org/pub/scm/linux/security/vulns.git/plain/cve/published/2022/CVE-2022-48845.mbox | https://bugzilla.suse.com/show_bug.cgi?id=1228070 |
| suse_bugzilla | https://bugzilla.redhat.com/show_bug.cgi?id=2298186 | https://bugzilla.suse.com/show_bug.cgi?id=1228070 |
| redhat_bugzilla | https://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git/commit/?id=76ce7cfe35ef | https://bugzilla.redhat.com/show_bug.cgi?id=2298186 |
| ubuntu | https://www.cve.org/CVERecord?id=CVE-2022-48845 | https://ubuntu.com/security/CVE-2022-48845 |
| ubuntu | https://git.kernel.org/linus/f2703def339c793674010cc9f01bfe4980231808 (5.17-rc7) | https://ubuntu.com/security/CVE-2022-48845 |
| ubuntu | https://git.kernel.org/stable/c/7315f8538db009605ffba00370678142ef00ac98 | https://ubuntu.com/security/CVE-2022-48845 |
| ubuntu | https://git.kernel.org/stable/c/32813321f18d5432cec1b1a6ecc964f9ea26d565 | https://ubuntu.com/security/CVE-2022-48845 |
| ubuntu | https://git.kernel.org/stable/c/56eaacb8137ba2071ce48d4e3d91979270e139a7 | https://ubuntu.com/security/CVE-2022-48845 |
| ubuntu | https://git.kernel.org/stable/c/c2420bc3333111184cdcb112282d13afe1338dd7 | https://ubuntu.com/security/CVE-2022-48845 |
| ubuntu | https://git.kernel.org/stable/c/e8ad9ecc406974deb5e7c070f51cc1d09d21dc4b | https://ubuntu.com/security/CVE-2022-48845 |
| ubuntu | https://git.kernel.org/stable/c/be538b764a46be1d0700fd3b6e82fb76bd17f13a | https://ubuntu.com/security/CVE-2022-48845 |
| ubuntu | https://git.kernel.org/stable/c/94647aec80d03d6914aa664b7b8e103cd9d63239 | https://ubuntu.com/security/CVE-2022-48845 |
| ubuntu | https://git.kernel.org/stable/c/f2703def339c793674010cc9f01bfe4980231808 | https://ubuntu.com/security/CVE-2022-48845 |
| ubuntu | https://nvd.nist.gov/vuln/detail/CVE-2022-48845 | https://ubuntu.com/security/CVE-2022-48845 |
| ubuntu | https://launchpad.net/bugs/cve/CVE-2022-48845 | https://ubuntu.com/security/CVE-2022-48845 |
| ubuntu | https://security-tracker.debian.org/tracker/CVE-2022-48845 | https://ubuntu.com/security/CVE-2022-48845 |
| cve_search |  | https://git.kernel.org/stable/c/7315f8538db009605ffba00370678142ef00ac98 |
| cve_search |  | https://git.kernel.org/stable/c/32813321f18d5432cec1b1a6ecc964f9ea26d565 |
| cve_search |  | https://git.kernel.org/stable/c/56eaacb8137ba2071ce48d4e3d91979270e139a7 |
| cve_search |  | https://git.kernel.org/stable/c/c2420bc3333111184cdcb112282d13afe1338dd7 |
| cve_search |  | https://git.kernel.org/stable/c/e8ad9ecc406974deb5e7c070f51cc1d09d21dc4b |
| cve_search |  | https://git.kernel.org/stable/c/be538b764a46be1d0700fd3b6e82fb76bd17f13a |
| cve_search |  | https://git.kernel.org/stable/c/94647aec80d03d6914aa664b7b8e103cd9d63239 |
| cve_search |  | https://git.kernel.org/stable/c/f2703def339c793674010cc9f01bfe4980231808 |

</details>

漏洞分析指导链接：
  https://gitee.com/openeuler/cve-manager/blob/master/cve-vulner-manager/doc/md/manual.md
 漏洞数据来源:
  openBrain开源漏洞感知系统
 漏洞补丁信息：
  <details>
<summary>详情(点击展开)</summary>

| 影响的包 | 修复版本 | 修复补丁 | 问题引入补丁 | 来源  |
| ------- | -------- | ------- | -------- | --------- |
|  |  | https://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git/commit/?id=76ce7cfe35ef |  | redhat_bugzilla |
| linux |  | https://git.kernel.org/linus/f2703def339c793674010cc9f01bfe4980231808 | https://git.kernel.org/linus/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 | ubuntu |

</details>

二、漏洞分析结构反馈
 影响性分析说明：
        In the Linux kernel, the following vulnerability has been resolved:MIPS: smp: fill in sibling and core maps earlierAfter enabling CONFIG_SCHED_CORE (landed during 5.14 cycle),2-core 2-thread-per-core interAptiv (CPS-driven) started emittingthe 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] [&lt;8105a7bc&gt;] show_stack+0x3c/0x140[    0.048424] [&lt;8131c2a0&gt;] dump_stack_lvl+0x60/0x80[    0.048440] [&lt;8108b5c0&gt;] __warn+0xc0/0xf4[    0.048454] [&lt;8108b658&gt;] warn_slowpath_fmt+0x64/0x10c[    0.048467] [&lt;810bd418&gt;] sched_core_cpu_starting+0x198/0x240[    0.048483] [&lt;810c6514&gt;] sched_cpu_starting+0x14/0x80[    0.048497] [&lt;8108c0f8&gt;] cpuhp_invoke_callback_range+0x78/0x140[    0.048510] [&lt;8108d914&gt;] notify_cpu_starting+0x94/0x140[    0.048523] [&lt;8106593c&gt;] 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 enteringthe function.This is critical, as sched_core_cpu_starting() calculatescore-scheduling parameters only once per CPU start, and it&#39;s crucialto have all the parameters filled in at that moment (at least ituses cpu_smt_mask() which in fact is `&#38;cpu_sibling_map[cpu]` onMIPS).A bit of debugging led me to that set_cpu_sibling_map() performingthe actual map calculation, was being invocated afternotify_cpu_start(), and exactly the latter function starts CPU HPcallback round (sched_core_cpu_starting() is basically a CPU HPcallback).While the flow is same on ARM64 (maps after the notifier, althoughbefore calling set_cpu_online()), x86 started calculating siblingmaps earlier than starting the CPU HP callbacks in Linux 4.14 (see[0] for the reference). Neither me nor my brief tests couldn&#39;t findany potential caveats in calculating the maps right after performingdelay calibration, but the WARN splat is now gone.The very same debug prints now yield exactly what I expected fromthem:[    0.048433] CPU: 1, smt_mask: 0-1[0] <ahref= https://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git/commit/?id=76ce7cfe35ef >https://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git/commit/?id=76ce7cfe35ef</a>The Linux kernel CVE team has assigned CVE-2022-48845 to this issue.   
 openEuler评分：
  5.5
 Vector：CVSS：3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
 受影响版本排查(受影响/不受影响)：
  1.openEuler-20.03-LTS-SP4(4.19.90):受影响
2.openEuler-22.03-LTS-SP1(5.10.0):不受影响
3.openEuler-22.03-LTS-SP3(5.10.0):不受影响
4.openEuler-22.03-LTS-SP4(5.10.0):不受影响
5.master(6.1.0):不受影响
6.openEuler-24.03-LTS(6.6.0):不受影响
7.openEuler-24.03-LTS-Next(6.6.0):不受影响

修复是否涉及abi变化(是/否)：
  1.openEuler-20.03-LTS-SP4(4.19.90):否
2.openEuler-22.03-LTS-SP1(5.10.0):否
3.openEuler-22.03-LTS-SP3(5.10.0):否
4.master(6.1.0):否
5.openEuler-24.03-LTS(6.6.0):否
6.openEuler-24.03-LTS-Next(6.6.0):否
7.openEuler-22.03-LTS-SP4(5.10.0):否

三、漏洞修复
安全公告链接：https://www.openeuler.org/zh/security/safety-bulletin/detail/?id=openEuler-SA-2024-1944

src-openEuler / kernel
Closed

Content Risk Flag

Comments (14)

src-openEuler / kernelClosed .gitee-modal { width: 500px !important; }

Content Risk Flag

CVE-2022-48845

Comments (14)

Search

src-openEuler / kernel
Closed