https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Tue, 29 Sep 2026 07:49:28 +0000 https://vulnerability.circl.lu/vuln/cve-2024-38613 <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>m68k: Fix spinlock race in kernel thread creation</p> <p>Context switching does take care to retain the correct lock owner across the switch from &#39;prev&#39; to &#39;next&#39; tasks. This does rely on interrupts remaining disabled for the entire duration of the switch.</p> <p>This condition is guaranteed for normal process creation and context switching between already running processes, because both &#39;prev&#39; and &#39;next&#39; already have interrupts disabled in their saved copies of the status register.</p> <p>The situation is different for newly created kernel threads. The status register is set to PS_S in copy_thread(), which does leave the IPL at 0. Upon restoring the &#39;next&#39; thread&#39;s status register in switch_to() aka resume(), interrupts then become enabled prematurely. resume() then returns via ret_from_kernel_thread() and schedule_tail() where run queue lock is released (see finish_task_switch() and finish_lock_switch()).</p> <p>A timer interrupt calling scheduler_tick() before the lock is released in finish_task_switch() will find the lock already taken, with the current task as lock owner. This causes a spinlock recursion warning as reported by Guenter Roeck.</p> <p>As far as I can ascertain, this race has been opened in commit 533e6903bea0 (&#34;m68k: split ret_from_fork(), simplify kernel_thread()&#34;) but I haven&#39;t done a detailed study of kernel history so it may well predate that commit.</p> <p>Interrupts cannot be disabled in the saved status register…</p> <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>m68k: Fix spinlock race in kernel thread creation</p> <p>Context switching does take care to retain the correct lock owner across the switch from &#39;prev&#39; to &#39;next&#39; tasks. This does rely on interrupts remaining disabled for the entire duration of the switch.</p> <p>This condition is guaranteed for normal process creation and context switching between already running processes, because both &#39;prev&#39; and &#39;next&#39; already have interrupts disabled in their saved copies of the status register.</p> <p>The situation is different for newly created kernel threads. The status register is set to PS_S in copy_thread(), which does leave the IPL at 0. Upon restoring the &#39;next&#39; thread&#39;s status register in switch_to() aka resume(), interrupts then become enabled prematurely. resume() then returns via ret_from_kernel_thread() and schedule_tail() where run queue lock is released (see finish_task_switch() and finish_lock_switch()).</p> <p>A timer interrupt calling scheduler_tick() before the lock is released in finish_task_switch() will find the lock already taken, with the current task as lock owner. This causes a spinlock recursion warning as reported by Guenter Roeck.</p> <p>As far as I can ascertain, this race has been opened in commit 533e6903bea0 (&#34;m68k: split ret_from_fork(), simplify kernel_thread()&#34;) but I haven&#39;t done a detailed study of kernel history so it may well predate that commit.</p> <p>Interrupts cannot be disabled in the saved status register…</p> https://vulnerability.circl.lu/vuln/cve-2024-38613