<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://vulnerability.circl.lu</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Wed, 30 Sep 2026 07:47:49 +0000</lastBuildDate>
    <item>
      <title>CVE-2024-58090 — sched/core: Prevent rescheduling when interrupts are disabled</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2024-58090</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;sched/core: Prevent rescheduling when interrupts are disabled&lt;/p&gt;
&lt;p&gt;David reported a warning observed while loop testing kexec jump:&lt;/p&gt;
&lt;p&gt;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&lt;/p&gt;
&lt;p&gt;The corresponding interrupt flag trace:&lt;/p&gt;
&lt;p&gt;hardirqs last  enabled at (15573): [&amp;lt;ffffffffa8281b8e&amp;gt;] __up_console_sem+0x7e/0x90
  hardirqs last disabled at (15580): [&amp;lt;ffffffffa8281b73&amp;gt;] __up_console_sem+0x63/0x90&lt;/p&gt;
&lt;p&gt;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:&lt;/p&gt;
&lt;p&gt;__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&lt;/p&gt;
&lt;p&gt;This is a long standing problem, which probably got more visible with
the recent printk changes. Something does a…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;sched/core: Prevent rescheduling when interrupts are disabled&lt;/p&gt;
&lt;p&gt;David reported a warning observed while loop testing kexec jump:&lt;/p&gt;
&lt;p&gt;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&lt;/p&gt;
&lt;p&gt;The corresponding interrupt flag trace:&lt;/p&gt;
&lt;p&gt;hardirqs last  enabled at (15573): [&amp;lt;ffffffffa8281b8e&amp;gt;] __up_console_sem+0x7e/0x90
  hardirqs last disabled at (15580): [&amp;lt;ffffffffa8281b73&amp;gt;] __up_console_sem+0x63/0x90&lt;/p&gt;
&lt;p&gt;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:&lt;/p&gt;
&lt;p&gt;__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&lt;/p&gt;
&lt;p&gt;This is a long standing problem, which probably got more visible with
the recent printk changes. Something does a…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2024-58090</guid>
    </item>
  </channel>
</rss>
