linux-cve-announce - CVE-2024-38613: m68k: Fix spinlock race in kernel thread creation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <2024061922-CVE-2024-38613-abc6@gregkh>
Date: Wed, 19 Jun 2024 15:56:26 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: linux-cve-announce@...r.kernel.org
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: CVE-2024-38613: m68k: Fix spinlock race in kernel thread creation

Description
===========

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

m68k: Fix spinlock race in kernel thread creation

Context switching does take care to retain the correct lock owner across
the switch from 'prev' to 'next' tasks.  This does rely on interrupts
remaining disabled for the entire duration of the switch.

This condition is guaranteed for normal process creation and context
switching between already running processes, because both 'prev' and
'next' already have interrupts disabled in their saved copies of the
status register.

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 'next' thread'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()).

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.

As far as I can ascertain, this race has been opened in commit
533e6903bea0 ("m68k: split ret_from_fork(), simplify kernel_thread()")
but I haven't done a detailed study of kernel history so it may well
predate that commit.

Interrupts cannot be disabled in the saved status register copy for
kernel threads (init will complain about interrupts disabled when
finally starting user space).  Disable interrupts temporarily when
switching 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 to
still be observed.

Tested on ARAnyM and qemu (Quadra 800 emulation).

The Linux kernel CVE team has assigned CVE-2024-38613 to this issue.

Affected and fixed versions
===========================

	Issue introduced in 3.7 with commit 533e6903bea0 and fixed in 4.19.316 with commit 2a8d1d95302c
	Issue introduced in 3.7 with commit 533e6903bea0 and fixed in 5.4.278 with commit 5213cc01d046
	Issue introduced in 3.7 with commit 533e6903bea0 and fixed in 5.10.219 with commit 4eeffecc8e3c
	Issue introduced in 3.7 with commit 533e6903bea0 and fixed in 5.15.161 with commit 77b2b67a0f8b
	Issue introduced in 3.7 with commit 533e6903bea0 and fixed in 6.1.93 with commit 0d9ae1253535
	Issue introduced in 3.7 with commit 533e6903bea0 and fixed in 6.6.33 with commit f3baf0f4f92a
	Issue introduced in 3.7 with commit 533e6903bea0 and fixed in 6.8.12 with commit f1d4274a84c0
	Issue introduced in 3.7 with commit 533e6903bea0 and fixed in 6.9.3 with commit 95f00caf767b
	Issue introduced in 3.7 with commit 533e6903bea0 and fixed in 6.10-rc1 with commit da89ce46f024

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2024-38613
will be updated if fixes are backported, please check that for the most
up to date information about this issue.

Affected files
==============

The file(s) affected by this issue are:
	arch/m68k/kernel/entry.S

Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/2a8d1d95302c7d52c6ac8fa5cb4a6948ae0d3a14
	https://git.kernel.org/stable/c/5213cc01d0464c011fdc09f318705603ed3a746b
	https://git.kernel.org/stable/c/4eeffecc8e3cce25bb559502c2fd94a948bcde82
	https://git.kernel.org/stable/c/77b2b67a0f8bce260c53907e5749d61466d90c87
	https://git.kernel.org/stable/c/0d9ae1253535f6e85a016e09c25ecbe6f7f59ef0
	https://git.kernel.org/stable/c/f3baf0f4f92af32943ebf27b960e0552c6c082fd
	https://git.kernel.org/stable/c/f1d4274a84c069be0f6098ab10c3443fc1f7134c
	https://git.kernel.org/stable/c/95f00caf767b5968c2c51083957b38be4748a78a
	https://git.kernel.org/stable/c/da89ce46f02470ef08f0f580755d14d547da59ed