Cloudanix VulnDB

CVE-2023-54232

None

CVSS

—

EPSS

0.2%

Published

Dec 30, 2025

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in older 68030 processors running Linux can cause the system to crash when trying to print internal task information.

Exploitation
Local Privilege
Attacker needs
High Privilege
Complexity
High
Impact
Denial Of Service
Component
OS kernel
Class
Memory Corruption
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

The m68k 030 bus error handler unconditionally sends SEGV or panics on supervisor-mode data faults without consulting the exception table, unlike 040/060 handlers, allowing faults from __get_kernel_nofault() during sysrq task backtraces to terminate unexpectedly.

Why it matters to the business

Systems running Linux on 68030 hardware may experience kernel panics or crashes when generating task backtraces, reducing reliability for embedded or legacy m68k deployments.

How an attack unfolds

An attacker with local access triggers a kernel task backtrace via /proc/sysrq_trigger on 030 hardware; the resulting bus error on a supervisor data access bypasses exception-table handling and forces a signal or panic.

How to fix it

Apply commit 1a6059f5ed57f48edfe7159404ff7d538d9d405b or later in the stable Linux kernel tree; rebuild and deploy the updated kernel on affected m68k 030 platforms.

How to confirm the fix worked

Confirm the running kernel contains commit 1a6059f5ed57f48edfe7159404ff7d538d9d405b; reproduce a sysrq backtrace on 030 hardware and verify it completes without panic or unexpected signal.

Typical attack path

  1. Gain local shell on m68k 030 system
  2. Write to /proc/sysrq_trigger to request task backtrace
  3. Cause NULL or unmapped kernel access during __get_kernel_nofault()
  4. Trigger unhandled bus error that panics or kills the process

How to detect it

Search kernel logs and crash dumps for m68k bus error messages, SEGV signals from supervisor faults, or panics during sysrq_trigger backtraces on 030 hardware.

  • bus error030
  • send_sig_fault
  • do_page_fault.*030
  • /proc/sysrq_trigger.*backtrace

What your security team should do

  • Identify all m68k 030 Linux systems and schedule kernel update to the fixed commit
  • Monitor kernel logs for bus error or page fault panics on 030 hardware
  • Disable non-essential sysrq triggers on exposed 030 systems until patched

The record

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.

Affected packages

Ecosystem Package Introduced Fixed
Linux Kernel 0 4.14.312
Linux Kernel 2.6.18 4.14.312

Related vulnerabilities