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

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: virtio: usar virtio_device_ready() en virtio_device_restore() Después de reactivar una máquina virtual suspendida, el kernel imprime el siguiente seguimiento para los controladores virtio que no llaman directamente a virtio_device_ready() en .restore: PM: suspender salir irq 22: a nadie le importó (intente arrancar con la opción "irqpoll") Seguimiento de llamada: dump_stack_lvl+0x38/0x49 dump_stack+0x10/0x12 __report_bad_irq+0x3a/0xaf note_interrupt.cold+0xb/0x60 handle_irq_event+0x71/0x80 handle_fasteoi_irq+0x95/0x1e0 __common_interrupt+0x6b/0x110 common_interrupt+0x63/0xe0 asm_common_interrupt+0x1e/0x40 ? __do_softirq+0x75/0x2f3 irq_exit_rcu+0x93/0xe0 sysvec_apic_timer_interrupt+0xac/0xd0 asm_sysvec_apic_timer_interrupt+0x12/0x20 arch_cpu_idle+0x12/0x20 default_idle_call+0x39/0xf0 do_idle+0x1b5/0x210 cpu_startup_entry+0x20/0x30 start_secondary+0xf3/0x100 secondary_startup_64_no_verify+0xc3/0xcb controladores: [<000000008f9bac49>] vp_interrupt [<000000008f9bac49>] vp_interrupt Deshabilitando IRQ #22 Esto sucede porque no invocamos la devolución de llamada .enable_cbs en virtio_device_restore(). Esa devolución de llamada es utilizada por algunos transportes (por ejemplo, virtio-pci) para habilitar interrupciones. Vamos a solucionarlo, llamando a virtio_device_ready() como lo hacemos en virtio_dev_probe(). Esta función llama a la devolución de llamada .enable_cts y establece el bit de estado DRIVER_OK. Esta solución también evita configurar DRIVER_OK dos veces para aquellos controladores que llaman a virtio_device_ready() en .restore.