GHSA-XJRQ-FPGW-9FHM

Vulnerability from github – Published: 2025-10-15 21:31 – Updated: 2025-10-15 21:31
VLAI
Details

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

virtio: use virtio_device_ready() in virtio_device_restore()

After waking up a suspended VM, the kernel prints the following trace for virtio drivers which do not directly call virtio_device_ready() 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 .enable_cbs callback in virtio_device_restore(). That callback is used by some transports (e.g. virtio-pci) to enable interrupts.

Let's fix it, by calling virtio_device_ready() as we do in virtio_dev_probe(). This function calls .enable_cts callback and sets DRIVER_OK status bit.

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

Severity
5.5 (Medium)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2022-49146"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-02-26T07:00:51Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nvirtio: use virtio_device_ready() in virtio_device_restore()\n\nAfter waking up a suspended VM, the kernel prints the following trace\nfor virtio drivers which do not directly call virtio_device_ready() in\nthe .restore:\n\n    PM: suspend exit\n    irq 22: nobody cared (try booting with the \"irqpoll\" option)\n    Call Trace:\n     \u003cIRQ\u003e\n     dump_stack_lvl+0x38/0x49\n     dump_stack+0x10/0x12\n     __report_bad_irq+0x3a/0xaf\n     note_interrupt.cold+0xb/0x60\n     handle_irq_event+0x71/0x80\n     handle_fasteoi_irq+0x95/0x1e0\n     __common_interrupt+0x6b/0x110\n     common_interrupt+0x63/0xe0\n     asm_common_interrupt+0x1e/0x40\n     ? __do_softirq+0x75/0x2f3\n     irq_exit_rcu+0x93/0xe0\n     sysvec_apic_timer_interrupt+0xac/0xd0\n     \u003c/IRQ\u003e\n     \u003cTASK\u003e\n     asm_sysvec_apic_timer_interrupt+0x12/0x20\n     arch_cpu_idle+0x12/0x20\n     default_idle_call+0x39/0xf0\n     do_idle+0x1b5/0x210\n     cpu_startup_entry+0x20/0x30\n     start_secondary+0xf3/0x100\n     secondary_startup_64_no_verify+0xc3/0xcb\n     \u003c/TASK\u003e\n    handlers:\n    [\u003c000000008f9bac49\u003e] vp_interrupt\n    [\u003c000000008f9bac49\u003e] vp_interrupt\n    Disabling IRQ #22\n\nThis happens because we don\u0027t invoke .enable_cbs callback in\nvirtio_device_restore(). That callback is used by some transports\n(e.g. virtio-pci) to enable interrupts.\n\nLet\u0027s fix it, by calling virtio_device_ready() as we do in\nvirtio_dev_probe(). This function calls .enable_cts callback and sets\nDRIVER_OK status bit.\n\nThis fix also avoids setting DRIVER_OK twice for those drivers that\ncall virtio_device_ready() in the .restore.",
  "id": "GHSA-xjrq-fpgw-9fhm",
  "modified": "2025-10-15T21:31:38Z",
  "published": "2025-10-15T21:31:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49146"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/4ae431113179d72c668b61df320af0c06d1aa5c5"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/8d65bc9a5be3f23c5e2ab36b6b8ef40095165b18"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/94e9f5da39ee5f8ea31be1585de31c54f10dedce"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.


Detection rules are retrieved from Rulezet.