CVE-2023-53331: pstore/ram: Check start of empty przs during init
In the Linux kernel, the following vulnerability has been resolved:
pstore/ram: Check start of empty przs during init
After commit 30696378f68a ("pstore/ram: Do not treat empty buffers as
valid"), initialization would assume a prz was valid after seeing that
the buffer_size is zero (regardless of the buffer start position). This
unchecked start value means it could be outside the bounds of the buffer,
leading to future access panics when written to:
sysdump_panic_event+0x3b4/0x5b8
atomic_notifier_call_chain+0x54/0x90
panic+0x1c8/0x42c
die+0x29c/0x2a8
die_kernel_fault+0x68/0x78
__do_kernel_fault+0x1c4/0x1e0
do_bad_area+0x40/0x100
do_translation_fault+0x68/0x80
do_mem_abort+0x68/0xf8
el1_da+0x1c/0xc0
__raw_writeb+0x38/0x174
__memcpy_toio+0x40/0xac
persistent_ram_update+0x44/0x12c
persistent_ram_write+0x1a8/0x1b8
ramoops_pstore_write+0x198/0x1e8
pstore_console_write+0x94/0xe0
...
To avoid this, also check if the prz start is 0 during the initialization
phase. If not, the next prz sanity check case will discover it (start >
size) and zap the buffer back to a sane state.
[kees: update commit log with backtrace and clarifications]
Security readout for executives and security teams
Plain-English summary
CVE-2023-53331 is a Linux kernel flaw in pstore/ram crash logging. Bad initialization of an empty persistent RAM zone can leave an out-of-bounds start value, causing later kernel memory access failures. The CVSS score is high at 7.8, but the vector is local and requires low privileges.
Executive priority
Treat this as a high-priority Linux kernel maintenance item for systems using persistent RAM crash logging. It is not currently sourced as actively exploited, but local low-privilege kernel impact justifies timely patching and reboot coordination, especially for shared, embedded, or appliance-like Linux environments.
Technical view
The bug is in Linux pstore/ram persistent RAM initialization after commit 30696378f68a. Empty buffers were treated as valid based on buffer_size alone, without checking start. A nonzero out-of-range start could later trigger out-of-bounds writes or panics during persistent_ram_write paths. The fix checks empty prz start during initialization.
Likely exposure
Exposure is most likely on Linux systems running affected kernel lines and using pstore/ram or ramoops persistent crash logging. The source lists affected Linux versions including 5.0, 4.14.326, 4.19.295, 5.4.257, 5.10.195, 5.15.132, 6.1.53, 6.4.16, 6.5.3, and 6.6. Distro backports may change status.
Exploitation context
The provided CVE data does not show CISA KEV listing or cited evidence of active exploitation. The CVSS vector is local, low complexity, low privilege, no user interaction, with high confidentiality, integrity, and availability impact. The bundle describes kernel panics from future writes, not a public exploit chain.
Researcher notes
The key condition is an empty persistent RAM zone with an unchecked nonzero start after the prior pstore/ram behavior change. Validate exposure through kernel lineage, pstore/ram or ramoops configuration, and whether the stable commit or distro backport is present. The bundle does not provide exploit details or a non-update mitigation.
Mitigation direction
Inventory Linux kernels and identify systems using pstore/ram or ramoops.
Apply vendor or Linux stable kernel updates containing the referenced fixes.
Prioritize reboot planning for exposed servers and appliances after kernel updates.
If no update exists, check vendor guidance for supported configuration mitigations.
Track distro advisories because backported fixes may not match upstream version numbers.
Validation and detection
Check running kernel versions against vendor advisories and the CVE record.
Confirm whether pstore/ram or ramoops is configured on each system.
Verify the deployed kernel includes one of the referenced stable fixes or vendor backport.
Review crash logging configuration and kernel logs for pstore/ram initialization issues.
Document exceptions where fixed packages are not yet available from the vendor.
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.
cwe · low confidence lookup
CWE-787: Exact CWE lookup
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
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.
1CVSS vectors
3Timeline events
1ADP providers
10Source links
SSVC decision data
CISA-ADPCISA Coordinator
Timestamp
Version
2.0.3
Exploitation: noneAutomatable: noTechnical Impact: total
CVSS vector scores
1 official score
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.
CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.
CWE-787 · source CWE mapping
Out-of-bounds Write
Out-of-bounds Write represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.