Wind River Support Network

Description

In the Linux kernel, the following vulnerability has been resolved:m68k: Fix spinlock race in kernel thread creationContext switching does take care to retain the correct lock owner acrossthe switch from 'prev' to 'next' tasks.  This does rely on interruptsremaining disabled for the entire duration of the switch.This condition is guaranteed for normal process creation and contextswitching between already running processes, because both 'prev' and'next' already have interrupts disabled in their saved copies of thestatus register.The situation is different for newly created kernel threads.  The statusregister is set to PS_S in copy_thread(), which does leave the IPL at 0.Upon restoring the 'next' thread's status register in switch_to() akaresume(), interrupts then become enabled prematurely.  resume() thenreturns via ret_from_kernel_thread() and schedule_tail() where run queuelock is released (see finish_task_switch() and finish_lock_switch()).A timer interrupt calling scheduler_tick() before the lock is releasedin finish_task_switch() will find the lock already taken, with thecurrent task as lock owner.  This causes a spinlock recursion warning asreported by Guenter Roeck.As far as I can ascertain, this race has been opened in commit533e6903bea0 ("m68k: split ret_from_fork(), simplify kernel_thread()")but I haven't done a detailed study of kernel history so it may wellpredate that commit.Interrupts cannot be disabled in the saved status register copy forkernel threads (init will complain about interrupts disabled whenfinally starting user space).  Disable interrupts temporarily whenswitching the tasks' register sets in resume().Note that a simple oriw 0x700,%sr after restoring sr is not enough here- this leaves enough of a race for the 'spinlock recursion' warning tostill be observed.Tested on ARAnyM and qemu (Quadra 800 emulation).

CREATE(Triage):(User=admin) CVE-2024-38613 (https://nvd.nist.gov/vuln/detail/CVE-2024-38613)

CVEs

• CVE-2024-38613