Vulnerabilidad en kernel de Linux (CVE-2023-53067)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: LoongArch: solo llamar a get_timer_irq() una vez en constant_clockevent_init() Bajo CONFIG_DEBUG_ATOMIC_SLEEP=y y CONFIG_DEBUG_PREEMPT=y, podemos ver los siguientes mensajes en LoongArch, esto se debe a que se usa might_sleep() en el contexto de deshabilitación de preempción. [ 0.001127] smp: Activando CPU secundarias... [ 0.001222] Arrancando CPU#1... [ 0.001244] Procesador Loongson de 64 bits probado (núcleo LA464) [ 0.001247] La revisión de CPU1 es: 0014c012 (Loongson-64bit) [ 0.001250] La revisión de FPU1 es: 00000000 [ 0.001252] ERROR: función de suspensión llamada desde un contexto no válido en kernel/locking/mutex.c:283 [ 0.001255] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 0, name: swapper/1 [ 0.001257] preempt_count: 1, expected: 0 [ 0.001258] Profundidad de anidamiento de RCU: 0, esperado: 0 [ 0.001259] Preempción deshabilitada en: [ 0.001261] [<9000000000223800>] arch_dup_task_struct+0x20/0x110 [ 0.001272] CPU: 1 PID: 0 Comm: swapper/1 No contaminado 6.2.0-rc7+ #43 [ 0.001275] Nombre del hardware: Loongson Loongson-3A5000-7A1000-1w-A2101/Loongson-LS3A5000-7A1000-1w-A2101, BIOS vUDK2018-LoongArch-V4.0.05132-beta10 12/13/202 [ 0.001277] Pila: 0072617764726148 0000000000000000 9000000000222f1c 90000001001e0000 [ 0.001286] 90000001001e3be0 90000001001e3be8 0000000000000000 000000000000000 [ 0.001292] 90000001001e3be8 0000000000000040 90000001001e3cb8 90000001001e3a50 [ 0.001297] 9000000001642000 90000001001e3be8 be694d10ce4139dd 9000000100174500 [ 0.001303] 0000000000000001 000000000000001 000000000ffffe0a2 0000000000000020 [ 0.001309] 00000000000002f 9000000001354116 00000000056b0000 ffffffffffffffffff [ 0.001314] 0000000000000000 0000000000000000 90000000014f6e90 9000000001642000 [ 0.001320] 900000000022b69c 0000000000000001 000000000000000 9000000001736a90 [ 0.001325] 9000000100038000 000000000000000 9000000000222f34 000000000000000 [ 0.001331] 00000000000000b0 0000000000000004 0000000000000000 0000000000070000 [ 0.001337] ... [ 0.001339] Rastreo de llamadas: [ 0.001342] [<9000000000222f34>] show_stack+0x5c/0x180 [ 0.001346] [<90000000010bdd80>] dump_stack_lvl+0x60/0x88 [ 0.001352] [<9000000000266418>] __might_resched+0x180/0x1cc [ 0.001356] [<90000000010c742c>] mutex_lock+0x20/0x64 [ 0.001359] [<90000000002a8ccc>] irq_find_matching_fwspec+0x48/0x124 [ 0.001364] [<90000000002259c4>] constant_clockevent_init+0x68/0x204 [ 0.001368] [<900000000022acf4>] start_secondary+0x40/0xa8 [ 0.001371] [<90000000010c0124>] smpboot_entry+0x60/0x64 Estas son las cadenas de llamadas completas: Para evitar el problema anterior, debemos romper las cadenas de llamadas, utilizando la variable timer_irq_installed como condición de verificación para llamar a get_timer_irq() solo una vez en constant_clockevent_init() es una forma simple y adecuada.