Message-ID: <2025123031-CVE-2023-54232-48af@gregkh>
Date: Tue, 30 Dec 2025 13:14:02 +0100
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: linux-cve-announce@...r.kernel.org
Cc: Greg Kroah-Hartman <gregkh@...nel.org>
Subject: CVE-2023-54232: m68k: Only force 030 bus error if PC not in exception table

From: Greg Kroah-Hartman <gregkh@...nel.org>

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

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

m68k: Only force 030 bus error if PC not in exception table

__get_kernel_nofault() does copy data in supervisor mode when
forcing a task backtrace log through /proc/sysrq_trigger.
This is expected cause a bus error exception on e.g. NULL
pointer dereferencing when logging a kernel task has no
workqueue associated. This bus error ought to be ignored.

Our 030 bus error handler is ill equipped to deal with this:

Whenever ssw indicates a kernel mode access on a data fault,
we don't even attempt to handle the fault and instead always
send a SEGV signal (or panic). As a result, the check
for exception handling at the fault PC (buried in
send_sig_fault() which gets called from do_page_fault()
eventually) is never used.

In contrast, both 040 and 060 access error handlers do not
care whether a fault happened on supervisor mode access,
and will call do_page_fault() on those, ultimately honoring
the exception table.

Add a check in bus_error030 to call do_page_fault() in case
we do have an entry for the fault PC in our exception table.

I had attempted a fix for this earlier in 2019 that did rely
on testing pagefault_disabled() (see link below) to achieve
the same thing, but this patch should be more generic.

Tested on 030 Atari Falcon.

The Linux kernel CVE team has assigned CVE-2023-54232 to this issue.


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

	Fixed in 4.14.312 with commit 1a6059f5ed57f48edfe7159404ff7d538d9d405b
	Fixed in 4.19.280 with commit f55cb52ec98b22125f5bda36391edb8894f7e8cf
	Fixed in 5.4.240 with commit 2100e374251a8fc00cce1916cfc50f3cb652cbe3
	Fixed in 5.10.177 with commit df1da53a7e98f0b2a0eb2241c154f148f2f2c1d8
	Fixed in 5.15.105 with commit 8bf8d5dade4c5e1d8a2386f29253ed28b5d87735
	Fixed in 6.1.22 with commit 54fa25ffab2b700df5abd58c136d64a912c53953
	Fixed in 6.2.9 with commit ec15405b80fc15ffc87a23d01378ae061c1aba07
	Fixed in 6.3 with commit e36a82bebbf7da814530d5a179bef9df5934b717

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-2023-54232
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/traps.c


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/1a6059f5ed57f48edfe7159404ff7d538d9d405b
	https://git.kernel.org/stable/c/f55cb52ec98b22125f5bda36391edb8894f7e8cf
	https://git.kernel.org/stable/c/2100e374251a8fc00cce1916cfc50f3cb652cbe3
	https://git.kernel.org/stable/c/df1da53a7e98f0b2a0eb2241c154f148f2f2c1d8
	https://git.kernel.org/stable/c/8bf8d5dade4c5e1d8a2386f29253ed28b5d87735
	https://git.kernel.org/stable/c/54fa25ffab2b700df5abd58c136d64a912c53953
	https://git.kernel.org/stable/c/ec15405b80fc15ffc87a23d01378ae061c1aba07
	https://git.kernel.org/stable/c/e36a82bebbf7da814530d5a179bef9df5934b717

Powered by blists - more mailing lists