CVE-2022-48845

{"id": "CVE-2022-48845", "cveTags": [], "metrics": {"cvssMetricV31": [{"type": "Primary", "source": "nvd@nist.gov", "cvssData": {"scope": "UNCHANGED", "version": "3.1", "baseScore": 5.5, "attackVector": "LOCAL", "baseSeverity": "MEDIUM", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H", "integrityImpact": "NONE", "userInteraction": "NONE", "attackComplexity": "LOW", "availabilityImpact": "HIGH", "privilegesRequired": "LOW", "confidentialityImpact": "NONE"}, "impactScore": 3.6, "exploitabilityScore": 1.8}]}, "published": "2024-07-16T13:15:11.803", "references": [{"url": "https://git.kernel.org/stable/c/32813321f18d5432cec1b1a6ecc964f9ea26d565", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/56eaacb8137ba2071ce48d4e3d91979270e139a7", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/7315f8538db009605ffba00370678142ef00ac98", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/94647aec80d03d6914aa664b7b8e103cd9d63239", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/be538b764a46be1d0700fd3b6e82fb76bd17f13a", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/c2420bc3333111184cdcb112282d13afe1338dd7", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/e8ad9ecc406974deb5e7c070f51cc1d09d21dc4b", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/f2703def339c793674010cc9f01bfe4980231808", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}], "vulnStatus": "Analyzed", "weaknesses": [{"type": "Primary", "source": "nvd@nist.gov", "description": [{"lang": "en", "value": "NVD-CWE-noinfo"}]}], "descriptions": [{"lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nMIPS: smp: fill in sibling and core maps earlier\n\nAfter enabling CONFIG_SCHED_CORE (landed during 5.14 cycle),\n2-core 2-thread-per-core interAptiv (CPS-driven) started emitting\nthe following:\n\n[ 0.025698] CPU1 revision is: 0001a120 (MIPS interAptiv (multi))\n[ 0.048183] ------------[ cut here ]------------\n[ 0.048187] WARNING: CPU: 1 PID: 0 at kernel/sched/core.c:6025 sched_core_cpu_starting+0x198/0x240\n[ 0.048220] Modules linked in:\n[ 0.048233] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.17.0-rc3+ #35 b7b319f24073fd9a3c2aa7ad15fb7993eec0b26f\n[ 0.048247] Stack : 817f0000 00000004 327804c8 810eb050 00000000 00000004 00000000 c314fdd1\n[ 0.048278] 830cbd64 819c0000 81800000 817f0000 83070bf4 00000001 830cbd08 00000000\n[ 0.048307] 00000000 00000000 815fcbc4 00000000 00000000 00000000 00000000 00000000\n[ 0.048334] 00000000 00000000 00000000 00000000 817f0000 00000000 00000000 817f6f34\n[ 0.048361] 817f0000 818a3c00 817f0000 00000004 00000000 00000000 4dc33260 0018c933\n[ 0.048389] ...\n[ 0.048396] Call Trace:\n[ 0.048399] [<8105a7bc>] show_stack+0x3c/0x140\n[ 0.048424] [<8131c2a0>] dump_stack_lvl+0x60/0x80\n[ 0.048440] [<8108b5c0>] __warn+0xc0/0xf4\n[ 0.048454] [<8108b658>] warn_slowpath_fmt+0x64/0x10c\n[ 0.048467] [<810bd418>] sched_core_cpu_starting+0x198/0x240\n[ 0.048483] [<810c6514>] sched_cpu_starting+0x14/0x80\n[ 0.048497] [<8108c0f8>] cpuhp_invoke_callback_range+0x78/0x140\n[ 0.048510] [<8108d914>] notify_cpu_starting+0x94/0x140\n[ 0.048523] [<8106593c>] start_secondary+0xbc/0x280\n[ 0.048539]\n[ 0.048543] ---[ end trace 0000000000000000 ]---\n[ 0.048636] Synchronize counters for CPU 1: done.\n\n...for each but CPU 0/boot.\nBasic debug printks right before the mentioned line say:\n\n[ 0.048170] CPU: 1, smt_mask:\n\nSo smt_mask, which is sibling mask obviously, is empty when entering\nthe function.\nThis is critical, as sched_core_cpu_starting() calculates\ncore-scheduling parameters only once per CPU start, and it's crucial\nto have all the parameters filled in at that moment (at least it\nuses cpu_smt_mask() which in fact is `&cpu_sibling_map[cpu]` on\nMIPS).\n\nA bit of debugging led me to that set_cpu_sibling_map() performing\nthe actual map calculation, was being invocated after\nnotify_cpu_start(), and exactly the latter function starts CPU HP\ncallback round (sched_core_cpu_starting() is basically a CPU HP\ncallback).\nWhile the flow is same on ARM64 (maps after the notifier, although\nbefore calling set_cpu_online()), x86 started calculating sibling\nmaps earlier than starting the CPU HP callbacks in Linux 4.14 (see\n[0] for the reference). Neither me nor my brief tests couldn't find\nany potential caveats in calculating the maps right after performing\ndelay calibration, but the WARN splat is now gone.\nThe very same debug prints now yield exactly what I expected from\nthem:\n\n[ 0.048433] CPU: 1, smt_mask: 0-1\n\n[0] https://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git/commit/?id=76ce7cfe35ef"}, {"lang": "es", "value": "En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: MIPS: smp: complete los mapas de hermanos y n\u00facleos antes Despu\u00e9s de habilitar CONFIG_SCHED_CORE (aterrizado durante el ciclo 5.14), se inici\u00f3 interAptiv de 2 n\u00facleos y 2 subprocesos por n\u00facleo (controlado por CPS) emitiendo lo siguiente: [0.025698] La revisi\u00f3n de CPU1 es: 0001a120 (MIPS interAptiv (multi)) [0.048183] ------------[ cortar aqu\u00ed ]------------ [0.048187] ADVERTENCIA: CPU: 1 PID: 0 en kernel/sched/core.c:6025 sched_core_cpu_starting+0x198/0x240 [0.048220] M\u00f3dulos vinculados en: [0.048233] CPU: 1 PID: 0 Comm: swapper/1 No contaminado 5.17 .0-rc3+ #35 b7b319f24073fd9a3c2aa7ad15fb7993eec0b26f [0.048247] Pila: 817f0000 00000004 327804c8 810eb050 00000000 00000004 00000000 c314fdd1 [ 0.048278] 830cbd64 819c0000 81800000 817f0000 83070bf4 00000001 830cbd08 00000000 [ 0.048307] 00000000 00000000 815fcbc 4 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] Seguimiento de llamadas: [ 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;] 198/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;] _secundario+0xbc/0x280 [ 0,048539] [ 0,048543] - --[ end trace 0000000000000000 ]--- [ 0.048636] Sincronizar contadores para CPU 1: hecho. ...para cada uno menos CPU 0/arranque. Las impresiones de depuraci\u00f3n b\u00e1sicas justo antes de la l\u00ednea mencionada dicen: [0.048170] CPU: 1, smt_mask: Entonces smt_mask, que obviamente es una m\u00e1scara hermana, est\u00e1 vac\u00eda al ingresar a la funci\u00f3n. Esto es cr\u00edtico, ya que sched_core_cpu_starting() calcula los par\u00e1metros de programaci\u00f3n central solo una vez por inicio de CPU, y es crucial tener todos los par\u00e1metros completados en ese momento (al menos usa cpu_smt_mask() que de hecho es `&amp;cpu_sibling_map[cpu]` en MIPS). Un poco de depuraci\u00f3n me llev\u00f3 a que set_cpu_sibling_map() realizaba el c\u00e1lculo del mapa real, se invocaba despu\u00e9s de notify_cpu_start(), y exactamente la \u00faltima funci\u00f3n inicia la ronda de devoluci\u00f3n de llamada de CPU HP (sched_core_cpu_starting() es b\u00e1sicamente una devoluci\u00f3n de llamada de CPU HP). Si bien el flujo es el mismo en ARM64 (mapas despu\u00e9s del notificador, aunque antes de llamar a set_cpu_online()), x86 comenz\u00f3 a calcular mapas de hermanos antes de iniciar las devoluciones de llamada de CPU HP en Linux 4.14 (consulte [0] para la referencia). Ni yo ni mis breves pruebas pudimos encontrar posibles advertencias al calcular los mapas justo despu\u00e9s de realizar la calibraci\u00f3n de retraso, pero el s\u00edmbolo WARN ya no est\u00e1. Las mismas impresiones de depuraci\u00f3n ahora producen exactamente lo que esperaba de ellas: [0.048433] CPU: 1, smt_mask: 0-1 [0] https://git.kernel.org/pub/scm/linux/kernel/git/mips /linux.git/commit/?id=76ce7cfe35ef"}], "lastModified": "2024-07-24T19:19:41.597", "configurations": [{"nodes": [{"negate": false, "cpeMatch": [{"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "0B50CF0F-1EB6-46C4-AFBA-C5492AC849BD", "versionEndExcluding": "4.9.308"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "A1E9CE4F-B0EA-4F88-9562-4F113E598085", "versionEndExcluding": "4.14.273", "versionStartIncluding": "4.10"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "09979837-E01F-4E28-B943-9F680CA3D278", "versionEndExcluding": "4.19.236", "versionStartIncluding": "4.15"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "F5FC3779-EA15-49D0-A021-B9224F651B97", "versionEndExcluding": "5.4.186", "versionStartIncluding": "4.20"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "295C9D5D-520B-4D0F-A53A-7C514F05B3D2", "versionEndExcluding": "5.10.107", "versionStartIncluding": "5.5"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "F1745C4F-8278-4F2E-9239-53C59154A03D", "versionEndExcluding": "5.15.30", "versionStartIncluding": "5.11"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "EDF25425-C006-411E-B842-0F12075B8C13", "versionEndExcluding": "5.16.16", "versionStartIncluding": "5.16"}], "operator": "OR"}]}], "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}