CVE-2022-48845

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: MIPS: smp: complete los mapas de hermanos y núcleos antes Después de habilitar CONFIG_SCHED_CORE (aterrizado durante el ciclo 5.14), se inició interAptiv de 2 núcleos y 2 subprocesos por núcleo (controlado por CPS) emitiendo lo siguiente: [0.025698] La revisión de CPU1 es: 0001a120 (MIPS interAptiv (multi)) [0.048183] ------------[ cortar aquí ]------------ [0.048187] ADVERTENCIA: CPU: 1 PID: 0 en kernel/sched/core.c:6025 sched_core_cpu_starting+0x198/0x240 [0.048220] Módulos 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] [<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>] 198/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>] _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ón básicas justo antes de la línea mencionada dicen: [0.048170] CPU: 1, smt_mask: Entonces smt_mask, que obviamente es una máscara hermana, está vacía al ingresar a la función. Esto es crítico, ya que sched_core_cpu_starting() calcula los parámetros de programación central solo una vez por inicio de CPU, y es crucial tener todos los parámetros completados en ese momento (al menos usa cpu_smt_mask() que de hecho es `&cpu_sibling_map[cpu]` en MIPS). Un poco de depuración me llevó a que set_cpu_sibling_map() realizaba el cálculo del mapa real, se invocaba después de notify_cpu_start(), y exactamente la última función inicia la ronda de devolución de llamada de CPU HP (sched_core_cpu_starting() es básicamente una devolución de llamada de CPU HP). Si bien el flujo es el mismo en ARM64 (mapas después del notificador, aunque antes de llamar a set_cpu_online()), x86 comenzó 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és de realizar la calibración de retraso, pero el símbolo WARN ya no está. Las mismas impresiones de depuración 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