CVE-2022-49146

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> virtio: use virtio_device_ready() in virtio_device_restore()<br /> <br /> After waking up a suspended VM, the kernel prints the following trace<br /> for virtio drivers which do not directly call virtio_device_ready() in<br /> the .restore:<br /> <br /> PM: suspend exit<br /> irq 22: nobody cared (try booting with the "irqpoll" option)<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x38/0x49<br /> dump_stack+0x10/0x12<br /> __report_bad_irq+0x3a/0xaf<br /> note_interrupt.cold+0xb/0x60<br /> handle_irq_event+0x71/0x80<br /> handle_fasteoi_irq+0x95/0x1e0<br /> __common_interrupt+0x6b/0x110<br /> common_interrupt+0x63/0xe0<br /> asm_common_interrupt+0x1e/0x40<br /> ? __do_softirq+0x75/0x2f3<br /> irq_exit_rcu+0x93/0xe0<br /> sysvec_apic_timer_interrupt+0xac/0xd0<br /> <br /> <br /> asm_sysvec_apic_timer_interrupt+0x12/0x20<br /> arch_cpu_idle+0x12/0x20<br /> default_idle_call+0x39/0xf0<br /> do_idle+0x1b5/0x210<br /> cpu_startup_entry+0x20/0x30<br /> start_secondary+0xf3/0x100<br /> secondary_startup_64_no_verify+0xc3/0xcb<br /> <br /> handlers:<br /> [] vp_interrupt<br /> [] vp_interrupt<br /> Disabling IRQ #22<br /> <br /> This happens because we don&amp;#39;t invoke .enable_cbs callback in<br /> virtio_device_restore(). That callback is used by some transports<br /> (e.g. virtio-pci) to enable interrupts.<br /> <br /> Let&amp;#39;s fix it, by calling virtio_device_ready() as we do in<br /> virtio_dev_probe(). This function calls .enable_cts callback and sets<br /> DRIVER_OK status bit.<br /> <br /> This fix also avoids setting DRIVER_OK twice for those drivers that<br /> call virtio_device_ready() in the .restore.