GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration

GHSA-WXJG-W4JC-V7MF

Vulnerability from github – Published: 2025-03-27 15:31 – Updated: 2025-11-03 21:33
VLAI
Details

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

sched/core: Prevent rescheduling when interrupts are disabled

David reported a warning observed while loop testing kexec jump:

Interrupts enabled after irqrouter_resume+0x0/0x50 WARNING: CPU: 0 PID: 560 at drivers/base/syscore.c:103 syscore_resume+0x18a/0x220 kernel_kexec+0xf6/0x180 __do_sys_reboot+0x206/0x250 do_syscall_64+0x95/0x180

The corresponding interrupt flag trace:

hardirqs last enabled at (15573): [] __up_console_sem+0x7e/0x90 hardirqs last disabled at (15580): [] __up_console_sem+0x63/0x90

That means __up_console_sem() was invoked with interrupts enabled. Further instrumentation revealed that in the interrupt disabled section of kexec jump one of the syscore_suspend() callbacks woke up a task, which set the NEED_RESCHED flag. A later callback in the resume path invoked cond_resched() which in turn led to the invocation of the scheduler:

__cond_resched+0x21/0x60 down_timeout+0x18/0x60 acpi_os_wait_semaphore+0x4c/0x80 acpi_ut_acquire_mutex+0x3d/0x100 acpi_ns_get_node+0x27/0x60 acpi_ns_evaluate+0x1cb/0x2d0 acpi_rs_set_srs_method_data+0x156/0x190 acpi_pci_link_set+0x11c/0x290 irqrouter_resume+0x54/0x60 syscore_resume+0x6a/0x200 kernel_kexec+0x145/0x1c0 __do_sys_reboot+0xeb/0x240 do_syscall_64+0x95/0x180

This is a long standing problem, which probably got more visible with the recent printk changes. Something does a task wakeup and the scheduler sets the NEED_RESCHED flag. cond_resched() sees it set and invokes schedule() from a completely bogus context. The scheduler enables interrupts after context switching, which causes the above warning at the end.

Quite some of the code paths in syscore_suspend()/resume() can result in triggering a wakeup with the exactly same consequences. They might not have done so yet, but as they share a lot of code with normal operations it's just a question of time.

The problem only affects the PREEMPT_NONE and PREEMPT_VOLUNTARY scheduling models. Full preemption is not affected as cond_resched() is disabled and the preemption check preemptible() takes the interrupt disabled flag into account.

Cure the problem by adding a corresponding check into cond_resched().

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-58090"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-03-27T15:15:54Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nsched/core: Prevent rescheduling when interrupts are disabled\n\nDavid reported a warning observed while loop testing kexec jump:\n\n  Interrupts enabled after irqrouter_resume+0x0/0x50\n  WARNING: CPU: 0 PID: 560 at drivers/base/syscore.c:103 syscore_resume+0x18a/0x220\n   kernel_kexec+0xf6/0x180\n   __do_sys_reboot+0x206/0x250\n   do_syscall_64+0x95/0x180\n\nThe corresponding interrupt flag trace:\n\n  hardirqs last  enabled at (15573): [\u003cffffffffa8281b8e\u003e] __up_console_sem+0x7e/0x90\n  hardirqs last disabled at (15580): [\u003cffffffffa8281b73\u003e] __up_console_sem+0x63/0x90\n\nThat means __up_console_sem() was invoked with interrupts enabled. Further\ninstrumentation revealed that in the interrupt disabled section of kexec\njump one of the syscore_suspend() callbacks woke up a task, which set the\nNEED_RESCHED flag. A later callback in the resume path invoked\ncond_resched() which in turn led to the invocation of the scheduler:\n\n  __cond_resched+0x21/0x60\n  down_timeout+0x18/0x60\n  acpi_os_wait_semaphore+0x4c/0x80\n  acpi_ut_acquire_mutex+0x3d/0x100\n  acpi_ns_get_node+0x27/0x60\n  acpi_ns_evaluate+0x1cb/0x2d0\n  acpi_rs_set_srs_method_data+0x156/0x190\n  acpi_pci_link_set+0x11c/0x290\n  irqrouter_resume+0x54/0x60\n  syscore_resume+0x6a/0x200\n  kernel_kexec+0x145/0x1c0\n  __do_sys_reboot+0xeb/0x240\n  do_syscall_64+0x95/0x180\n\nThis is a long standing problem, which probably got more visible with\nthe recent printk changes. Something does a task wakeup and the\nscheduler sets the NEED_RESCHED flag. cond_resched() sees it set and\ninvokes schedule() from a completely bogus context. The scheduler\nenables interrupts after context switching, which causes the above\nwarning at the end.\n\nQuite some of the code paths in syscore_suspend()/resume() can result in\ntriggering a wakeup with the exactly same consequences. They might not\nhave done so yet, but as they share a lot of code with normal operations\nit\u0027s just a question of time.\n\nThe problem only affects the PREEMPT_NONE and PREEMPT_VOLUNTARY scheduling\nmodels. Full preemption is not affected as cond_resched() is disabled and\nthe preemption check preemptible() takes the interrupt disabled flag into\naccount.\n\nCure the problem by adding a corresponding check into cond_resched().",
  "id": "GHSA-wxjg-w4jc-v7mf",
  "modified": "2025-11-03T21:33:13Z",
  "published": "2025-03-27T15:31:10Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58090"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/0362847c520747b44b574d363705d8af0621727a"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/1651f5731b378616565534eb9cda30e258cebebc"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/288fdb8dcb71ec77b76ab8b8a06bc10f595ea504"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/321794b75ac968f0bb6b9c913581949452a8d992"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/68786ab0935ccd5721283b7eb7f4d2f2942c7a52"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/82c387ef7568c0d96a918a5a78d9cad6256cfa15"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/84586322e010164eedddfcd0a0894206ae7d9317"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/b927c8539f692fb1f9c2f42e6c8ea2d94956f921"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html"
    }
  ],
  "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.


Loading…

Loading…

Loading…

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.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.


Loading…