CVE-2024-38613

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> m68k: Fix spinlock race in kernel thread creation<br /> <br /> Context switching does take care to retain the correct lock owner across<br /> the switch from &amp;#39;prev&amp;#39; to &amp;#39;next&amp;#39; tasks. This does rely on interrupts<br /> remaining disabled for the entire duration of the switch.<br /> <br /> This condition is guaranteed for normal process creation and context<br /> switching between already running processes, because both &amp;#39;prev&amp;#39; and<br /> &amp;#39;next&amp;#39; already have interrupts disabled in their saved copies of the<br /> status register.<br /> <br /> The situation is different for newly created kernel threads. The status<br /> register is set to PS_S in copy_thread(), which does leave the IPL at 0.<br /> Upon restoring the &amp;#39;next&amp;#39; thread&amp;#39;s status register in switch_to() aka<br /> resume(), interrupts then become enabled prematurely. resume() then<br /> returns via ret_from_kernel_thread() and schedule_tail() where run queue<br /> lock is released (see finish_task_switch() and finish_lock_switch()).<br /> <br /> A timer interrupt calling scheduler_tick() before the lock is released<br /> in finish_task_switch() will find the lock already taken, with the<br /> current task as lock owner. This causes a spinlock recursion warning as<br /> reported by Guenter Roeck.<br /> <br /> As far as I can ascertain, this race has been opened in commit<br /> 533e6903bea0 ("m68k: split ret_from_fork(), simplify kernel_thread()")<br /> but I haven&amp;#39;t done a detailed study of kernel history so it may well<br /> predate that commit.<br /> <br /> Interrupts cannot be disabled in the saved status register copy for<br /> kernel threads (init will complain about interrupts disabled when<br /> finally starting user space). Disable interrupts temporarily when<br /> switching the tasks&amp;#39; register sets in resume().<br /> <br /> Note that a simple oriw 0x700,%sr after restoring sr is not enough here<br /> - this leaves enough of a race for the &amp;#39;spinlock recursion&amp;#39; warning to<br /> still be observed.<br /> <br /> Tested on ARAnyM and qemu (Quadra 800 emulation).