Vulnerabilidad en kernel de Linux (CVE-2021-46961)

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: irqchip/gic-v3: no habilitar irqs cuando se manejan interrupciones espurias. Activamos el siguiente error al ejecutar nuestro kernel 4.19 con los parches pseudo-NMI respaldados: [14.816231] - -----------[ cortar aquí ]------------ ¡ERROR del kernel [14.816231] en irq.c:99! [14.816232] Error interno: Ups - ERROR: 0 [#1] SMP [14.816232] Intercambiador de procesos/0 (pid: 0, límite de pila = 0x(____ptrval____)) [14.816233] CPU: 0 PID: 0 Comunicaciones: intercambiador/0 Contaminado: GO 4.19.95.aarch64 #14 [ 14.816233] Nombre de hardware: evb (DT) [ 14.816234] pstate: 80400085 (Nzcv daIf +PAN -UAO) [ 14.816234] pc : asm_nmi_enter+0x94/0x98 [ 14.816235] lr : asm_nmi_enter +0x18/0x98 [ 14.816235] sp : ffff000008003c50 [ 14.816235] pmr_save: 00000070 [ 14.816237] x29: ffff000008003c50 x28: ffff0000095f56c0 [ 14.816 238] x27: 0000000000000000 x26: ffff000008004000 [ 14.816239] x25: 00000000015e0000 x24: ffff8008fb916000 [ 14.816240] x23: 000000002040 0005x22 : ffff0000080817cc [ 14.816241] x21: ffff000008003da0 x20: 0000000000000060 [ 14.816242] x19: 00000000000003ff x18: ffffffffffffffff [ 14.816243] x 17: 0000000000000008 x16: 003d090000000000 [ 14.816244] x15: ffff0000095ea6c8 x14: ffff8008fff5ab40 [ 14.816244] x13: ffff8008fff58b9d x12: 00 00000000000000 [14.816245] x11: ffff000008c8a200 x10: 000000008e31fca5 [ 14.816246] x9 : ffff000008c8a208 x8 : 0000000000000000f [ 14.816247] x7 : 0000000000000004 x6 : ffff8008fff58b9e [ 14.816248] x5 : 00000000000000000 x4 : 0000000080000000 [ 14.816249] x3 : 00000000000000000 x2 : 0000000080000000 [ 14.81 6250] x1: 0000000000120000 x0: ffff0000095f56c0 [ 14.816251] Rastreo de llamadas: [ 14.816251] asm_nmi_enter+0x94/0x98 [ 14.816251] el1_irq+0x8c/0x180 (IRQ C) [ 14.816252] gic_handle_irq+0xbc/0x2e4 [ 14.816252] el1_irq+0xcc/0x180 (IRQ B) [ 14.816253] arch_timer_handler_virt+0x38/0x58 [ 14.816253] handle_percpu_devid_irq+0x90/0x240 [ 14.816253] generic_handle_irq+0x34/0x50 [ 14.816254] __handle_domain_irq+0x68/0xc0 [ 14.81625 4] gic_handle_irq+0xf8/0x2e4 [ 14.816255] el1_irq+0xcc/0x180 (IRQ A) [ 14.816255] arch_cpu_idle+0x34/0x1c8 [ 14.816255] default_idle_call+0x24/0x44 [ 14.816256] do_idle+0x1d0/0x2c8 [ 14.816256] cpu_startup_entry+0x28/0x30 [ 14.8162 56] rest_init+0xb8/0xc8 [ 14.816257] start_kernel+0x4c8/0x4f4 [ 14.816257] Código: 940587f1 d5384100 b9401001 36a7fd01 (d4210000) [14.816258] Módulos vinculados en: start_dp(O) smeth(O) [15.103092] ---[ end trace 701753956cb14aa8 ]--- [ 15.1030 93] Pánico en el kernel: no se sincroniza: excepción fatal en interrupción [15.103099] SMP: deteniendo CPU secundarias [15.103100] Desplazamiento del kernel: deshabilitado [15.103100] Características de la CPU: 0x36,a2400218 [15.103100] Límite de memoria: ninguno causado por un 'BUG_ON(in_nmi())' en nmi_enter(). Desde el seguimiento de la llamada, podemos encontrar tres interrupciones (anotadas A, B, C arriba): la interrupción (A) es reemplazada por (B), que es interrumpida aún más por (C). Investigaciones posteriores muestran que (B) da como resultado que se llame a nmi_enter(), pero que en realidad es una interrupción espuria. Además, las interrupciones se vuelven a habilitar en el contexto de incendios (B) y (C) con prioridad NMI. Terminamos con una situación de NMI anidada, algo que definitivamente no queremos (y no podemos) manejar. El error aquí es que las interrupciones espurias nunca deberían dar lugar a ningún cambio de estado y simplemente deberíamos volver al contexto interrumpido. Mover el manejo de interrupciones espurias lo antes posible en el controlador GICv3 soluciona este problema. [maz: reescribí el mensaje de confirmación, corregido Correcciones: etiqueta]