CVE-2023-54232: 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...

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.

Metrics

EPSS Probability

0.18%

7.5th percentile

Probability of exploitation in the next 30 days. Learn more

Affected Software

Source: CNA advisory (CVE.org). NVD analysis pending.

Vendor	Product	Versions
Linux	Linux	>= f2325ecebc5b7988fd49968bd3a660fd1594dc84, < 1a6059f5ed57f48edfe7159404ff7d538d9d405b; >= f2325ecebc5b7988fd49968bd3a660fd1594dc84, < f55cb52ec98b22125f5bda36391edb8894f7e8cf; >= f2325ecebc5b7988fd49968bd3a660fd1594dc84, < 2100e374251a8fc00cce1916cfc50f3cb652cbe3; >= f2325ecebc5b7988fd49968bd3a660fd1594dc84, < df1da53a7e98f0b2a0eb2241c154f148f2f2c1d8; >= f2325ecebc5b7988fd49968bd3a660fd1594dc84, < 8bf8d5dade4c5e1d8a2386f29253ed28b5d87735; >= f2325ecebc5b7988fd49968bd3a660fd1594dc84, < 54fa25ffab2b700df5abd58c136d64a912c53953; >= f2325ecebc5b7988fd49968bd3a660fd1594dc84, < ec15405b80fc15ffc87a23d01378ae061c1aba07; >= f2325ecebc5b7988fd49968bd3a660fd1594dc84, < e36a82bebbf7da814530d5a179bef9df5934b717
Linux	Linux	2.6.18

References

Timeline

Published: Dec 30, 2025
Last Modified: Jun 17, 2026
Status: Deferred

Frequently Asked Questions

What is CVE-2023-54232?

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.

How severe is CVE-2023-54232?

Severity scoring for CVE-2023-54232 is pending analysis. The EPSS model estimates a 0.18% probability of exploitation in the next 30 days.

How do I fix CVE-2023-54232?

Check the vendor references and advisories linked above for patched versions and mitigation guidance. You can also run a Strix scan to test if your systems are affected.

How Strix Helps

Related CVEs from 2023

View all 2023CVEs →