Vulnerabilidad en kernel de Linux (CVE-2022-49782)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: perf: Mejora de la comprobación de SIGTRAP faltantes. Para detectar la falta de SIGTRAP, empleamos una advertencia en __perf_event_overflow(), que se activa si pending_sigtrap ya estaba configurado: al regresar al espacio de usuario sin consumir pending_sigtrap y luego volver a activar el evento, se reingresaría al kernel y se activaría la advertencia. Sin embargo, esto parecía pasar por alto el caso en el que algunos eventos no asociados con el progreso en la tarea del espacio de usuario pueden activarse y el controlador de interrupciones se ejecuta antes del trabajo de IRQ destinado a consumir pending_sigtrap (y generar la SIGTRAP). syzbot nos proporcionó este seguimiento de pila: | ADVERTENCIA: CPU: 0 PID: 3607 en kernel/events/core.c:9313 __perf_event_overflow | Módulos enlazados en: | CPU: 0 PID: 3607 Comm: syz-executor100 No contaminado 6.1.0-rc2-syzkaller-00073-g88619e77b33d #0 | Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/11/2022 | RIP: 0010:__perf_event_overflow+0x498/0x540 kernel/events/core.c:9313 | <...> | Seguimiento de llamadas: | | perf_swevent_hrtimer+0x34f/0x3c0 kernel/events/core.c:10729 | __run_hrtimer kernel/time/hrtimer.c:1685 [inline] | __hrtimer_run_queues+0x1c6/0xfb0 kernel/time/hrtimer.c:1749 | hrtimer_interrupt+0x31c/0x790 kernel/time/hrtimer.c:1811 | local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1096 [inline] | __sysvec_apic_timer_interrupt+0x17c/0x640 arch/x86/kernel/apic/apic.c:1113 | sysvec_apic_timer_interrupt+0x40/0xc0 arch/x86/kernel/apic/apic.c:1107 | asm_sysvec_apic_timer_interrupt+0x16/0x20 arch/x86/include/asm/idtentry.h:649 | <...> | En este caso, syzbot generó un programa con el tipo de evento PERF_TYPE_SOFTWARE y la configuración PERF_COUNT_SW_CPU_CLOCK. El temporizador hrtimer se vuelve a ejecutar antes de que el trabajo de IRQ tenga la oportunidad de ejecutarse, sin haber regresado al espacio de usuario. Mejore el WARN para comprobar el progreso real en el espacio de usuario: aproxime esto almacenando un hash de 32 bits de la IP actual en pending_sigtrap. Si un evento se dispara mientras pending_sigtrap aún coincide con la IP anterior, asumimos que no hay progreso (los falsos negativos son posibles dado que podríamos regresar al espacio de usuario y disparar de nuevo en la misma IP).