CVE-2022-49146

In the Linux kernel, the following vulnerability has been resolved:

virtio: use virtiodeviceready() in virtiodevicerestore()

After waking up a suspended VM, the kernel prints the following trace for virtio drivers which do not directly call virtiodeviceready() in the .restore:

PM: suspend exit
irq 22: nobody cared (try booting with the "irqpoll" option)
Call Trace:
 <IRQ>
 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
 </IRQ>
 <TASK>
 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
 </TASK>
handlers:
[<000000008f9bac49>] vp_interrupt
[<000000008f9bac49>] vp_interrupt
Disabling IRQ #22

This happens because we don't invoke .enablecbs callback in virtiodevice_restore(). That callback is used by some transports (e.g. virtio-pci) to enable interrupts.

Let's fix it, by calling virtiodeviceready() as we do in virtiodevprobe(). This function calls .enablects callback and sets DRIVEROK status bit.

This fix also avoids setting DRIVEROK twice for those drivers that call virtiodevice_ready() in the .restore.