CVE-2024-36888

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: workqueue: Se corrigió la selección de wake_cpu en kick_pool() Con cpu_possible_mask=0-63 y cpu_online_mask=0-7 se observaron los siguientes errores del kernel: smp: Apareciendo CPU secundarias... smp: abrió 1 nodo, 8 CPU No se puede manejar la desreferencia del puntero del kernel en el espacio de direcciones virtual del kernel Dirección fallida: 0000000000000000 TEID: 0000000000000803 [..] Seguimiento de llamadas: arch_vcpu_is_preempted+0x12/0x80 select_idle_sibling+0x42/0x560 _rq_fair+0x29a/0x3b0 intenta_despertar_up +0x38e/0x6e0 kick_pool+0xa4/0x198 __queue_work.part.0+0x2bc/0x3a8 call_timer_fn+0x36/0x160 __run_timers+0x1e2/0x328 __run_timer_base+0x5a/0x88 run_timer_softirq+0x40/0x78 irq+0x118/0x388 irq_exit_rcu+0xc0/0xd8 hacer_ext_irq+ 0xae/0x168 ext_int_handler+0xbe/0xf0 psw_idle_exit+0x0/0xc default_idle_call+0x3c/0x110 do_idle+0xd4/0x158 cpu_startup_entry+0x40/0x48 rest_init+0xc6/0xc8 startup_continue+0x3c/0x50 El bloqueo se produce al llamar a arch_vcpu_is_preempted () para una CPU fuera de línea. Para evitar esto, seleccione la CPU con cpumask_any_and_distribute() para enmascarar __pod_cpumask con cpu_online_mask. En caso de que no quede ninguna CPU en el grupo, omita la tarea. tj: Esto no soluciona completamente el error ya que las CPU aún pueden fallar entre la selección de la CPU de destino y la llamada de activación. Para solucionarlo, es probable que sea necesario agregar la prueba cpu_online() al código arch sched o s390. Sin embargo, independientemente de cómo se solucione, workqueue no debería elegir una CPU que no esté en línea, ya que eso resultaría en un comportamiento peor e impredecible.

In the Linux kernel, the following vulnerability has been resolved: workqueue: Fix selection of wake_cpu in kick_pool() With cpu_possible_mask=0-63 and cpu_online_mask=0-7 the following kernel oops was observed: smp: Bringing up secondary CPUs ... smp: Brought up 1 node, 8 CPUs Unable to handle kernel pointer dereference in virtual kernel address space Failing address: 0000000000000000 TEID: 0000000000000803 [..] Call Trace: arch_vcpu_is_preempted+0x12/0x80 select_idle_sibling+0x42/0x560 select_task_rq_fair+0x29a/0x3b0 try_to_wake_up+0x38e/0x6e0 kick_pool+0xa4/0x198 __queue_work.part.0+0x2bc/0x3a8 call_timer_fn+0x36/0x160 __run_timers+0x1e2/0x328 __run_timer_base+0x5a/0x88 run_timer_softirq+0x40/0x78 __do_softirq+0x118/0x388 irq_exit_rcu+0xc0/0xd8 do_ext_irq+0xae/0x168 ext_int_handler+0xbe/0xf0 psw_idle_exit+0x0/0xc default_idle_call+0x3c/0x110 do_idle+0xd4/0x158 cpu_startup_entry+0x40/0x48 rest_init+0xc6/0xc8 start_kernel+0x3c4/0x5e0 startup_continue+0x3c/0x50 The crash is caused by calling arch_vcpu_is_preempted() for an offline CPU. To avoid this, select the cpu with cpumask_any_and_distribute() to mask __pod_cpumask with cpu_online_mask. In case no cpu is left in the pool, skip the assignment. tj: This doesn't fully fix the bug as CPUs can still go down between picking the target CPU and the wake call. Fixing that likely requires adding cpu_online() test to either the sched or s390 arch code. However, regardless of how that is fixed, workqueue shouldn't be picking a CPU which isn't online as that would result in unpredictable and worse behavior.

Benedict Schlüter, Supraja Sridhara, Andrin Bertschi, and Shweta Shinde discovered that an untrusted hypervisor could inject malicious #VC interrupts and compromise the security guarantees of AMD SEV-SNP. This flaw is known as WeSee. A local attacker in control of the hypervisor could use this to expose sensitive information or possibly execute arbitrary code in the trusted execution environment. Several security issues were discovered in the Linux kernel. An attacker could possibly use these to compromise the system.