CVE-2023-54278: s390/vmem: split pages when debug pagealloc is enabled
In the Linux kernel, the following vulnerability has been resolved:
s390/vmem: split pages when debug pagealloc is enabled
Since commit bb1520d581a3 ("s390/mm: start kernel with DAT enabled")
the kernel crashes early during boot when debug pagealloc is enabled:
mem auto-init: stack:off, heap alloc:off, heap free:off
addressing exception: 0005 ilc:2 [#1] SMP DEBUG_PAGEALLOC
Modules linked in:
CPU: 0 PID: 0 Comm: swapper Not tainted 6.5.0-rc3-09759-gc5666c912155 #630
[..]
Krnl Code: 00000000001325f6: ec5600248064 cgrj %r5,%r6,8,000000000013263e
00000000001325fc: eb880002000c srlg %r8,%r8,2
#0000000000132602: b2210051 ipte %r5,%r1,%r0,0
>0000000000132606: b90400d1 lgr %r13,%r1
000000000013260a: 41605008 la %r6,8(%r5)
000000000013260e: a7db1000 aghi %r13,4096
0000000000132612: b221006d ipte %r6,%r13,%r0,0
0000000000132616: e3d0d0000171 lay %r13,4096(%r13)
Call Trace:
__kernel_map_pages+0x14e/0x320
__free_pages_ok+0x23a/0x5a8)
free_low_memory_core_early+0x214/0x2c8
memblock_free_all+0x28/0x58
mem_init+0xb6/0x228
mm_core_init+0xb6/0x3b0
start_kernel+0x1d2/0x5a8
startup_continue+0x36/0x40
Kernel panic - not syncing: Fatal exception: panic_on_oops
This is caused by using large mappings on machines with EDAT1/EDAT2. Add
the code to split the mappings into 4k pages if debug pagealloc is enabled
by CONFIG_DEBUG_PAGEALLOC_ENABLE_DEFAULT or the debug_pagealloc kernel
command line option.
Security readout for executives and security teams
Plain-English summary
This is a Linux kernel boot-stability flaw on s390 systems. When debug page allocation is enabled, affected kernels can crash early during startup. The business impact is availability: affected IBM Z/Linux systems may fail to boot under the specific debug-pagealloc configuration.
Executive priority
Treat this as a targeted availability risk, not a broad emergency. Prioritize organizations running Linux on IBM Z/s390 with debug page allocation enabled, especially where reboot failure would affect critical services or maintenance windows.
Technical view
The issue is in Linux s390 virtual memory handling after commit bb1520d581a3. On EDAT1/EDAT2 machines, large mappings conflict with debug pagealloc behavior, causing an addressing exception and kernel panic. The cited fix splits mappings into 4 KB pages when debug pagealloc is enabled.
Likely exposure
Exposure appears narrow: Linux on s390 architecture, machines with EDAT1/EDAT2, and debug pagealloc enabled through CONFIG_DEBUG_PAGEALLOC_ENABLE_DEFAULT or the debug_pagealloc kernel option. The source lists Linux 6.3, 6.4.10, and 6.5 data, but affected range details are limited in the bundle.
Exploitation context
No active exploitation is indicated. The CVE is not listed as KEV in the provided bundle, and the described failure is an early boot kernel panic under a specific diagnostic/debug configuration rather than a remote attack path.
Researcher notes
The source evidence describes a resolved kernel crash, affected s390 memory mapping behavior, and two stable commits. It does not provide CVSS, CWE, exploitability analysis, or a complete vendor-specific affected-version matrix. Avoid generalizing beyond s390 debug-pagealloc exposure.
Mitigation direction
Review vendor kernel advisories for s390 updates containing the cited stable fixes.
Prioritize patching affected s390 systems that boot with debug_pagealloc enabled.
Avoid enabling debug pagealloc on production s390 systems unless required and validated.
Test kernel updates on representative EDAT1/EDAT2 hardware or virtualized s390 environments.
Validation and detection
Check whether systems are Linux on s390 architecture with EDAT1 or EDAT2 support.
Confirm whether CONFIG_DEBUG_PAGEALLOC_ENABLE_DEFAULT is enabled in the kernel build.
Review boot parameters for the debug_pagealloc option.
Compare installed kernel versions against vendor advisories and the cited stable commits.
Validate that patched kernels boot successfully with debug pagealloc enabled.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2023-54278 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
0CVSS vectors
3Timeline events
0ADP providers
3Source links
Vulnerability timeline
Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.
CVE reservedCVE Program
The CVE ID was reserved by the assigning CNA.
CVE publishedCVE Program
The CVE record was published.
Dec 30, 2025, 12:16 UTC (UTC+00:00)
CVE updatedCVE Program
The CVE record metadata indicates this as the latest update time.