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

pstore/ram: fix buffer overflow in persistent_ram_save_old()

persistent_ram_save_old() can be called multiple times for the same
persistent_ram_zone (e.g., via ramoops_pstore_read -> ramoops_get_next_prz
for PSTORE_TYPE_DMESG records).

Currently, the function only allocates prz->old_log when it is NULL,
but it unconditionally updates prz->old_log_size to the current buffer
size and then performs memcpy_fromio() using this new size. If the
buffer size has grown since the first allocation (which can happen
across different kernel boot cycles), this leads to:

1. A heap buffer overflow (OOB write) in the memcpy_fromio() calls
2. A subsequent OOB read when ramoops_pstore_read() accesses the buffer
using the incorrect (larger) old_log_size

The KASAN splat would look similar to:
BUG: KASAN: slab-out-of-bounds in ramoops_pstore_read+0x...
Read of size N at addr ... by task ...

The conditions are likely extremely hard to hit:

0. Crash with a ramoops write of less-than-record-max-size bytes.
1. Reboot: ramoops registers, pstore_get_records(0) reads old crash,
allocates old_log with size X
2. Crash handler registered, timer started (if pstore_update_ms >= 0)
3. Oops happens (non-fatal, system continues)
4. pstore_dump() writes oops via ramoops_pstore_write() size Y (>X)
5. pstore_new_entry = 1, pstore_timer_kick() called
6. System continues running (not a panic oops)
7. Timer fires after pstore_update_ms milliseconds
8. pstore_timefunc() → schedule_work() → pstore_dowork() → pstore_get_records(1)
9. ramoops_get_next_prz() → persistent_ram_save_old()
10. buffer_size() returns Y, but old_log is X bytes
11. Y > X: memcpy_fromio() overflows heap

Requirements:
- a prior crash record exists that did not fill the record size
(almost impossible since the crash handler writes as much as it
can possibly fit into the record, capped by max record size and
the kmsg buffer almost always exceeds the max record size)
- pstore_update_ms >= 0 (disabled by default)
- Non-fatal oops (system survives)

Free and reallocate the buffer when the new size differs from the
previously allocated size. This ensures old_log always has sufficient
space for the data being copied.
Published: 2026-06-03
Score: 7.8 High
EPSS: < 1% Very Low
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

The vulnerability originates from a heap buffer overflow in the persistent_ram_save_old() routine in the kernel’s pstore/ram subsystem. When the function updates its old_log buffer without checking that the new size differs from the previous allocation, memcpy_fromio() can write beyond the allocated space, followed by an out‑of‑bounds read during subsequent pstore read operations, corrupting kernel memory and potentially leading to denial of service or other integrity violations.

Affected Systems

All Linux kernel builds that enable pstore and ramoops before the inclusion of the patch are impacted. The code path is part of the generic Linux kernel; any distribution using a kernel older than the commit that adds the buffer reallocation safety (prior to the fix) is susceptible, regardless of configuration.

Risk and Exploitability

The CVSS score is 7.8. The EPSS score is < 1%, indicating a very low probability of exploitation, and the vulnerability is not listed in the CISA KEV catalog. The exploit chain requires a non‑fatal kernel oops, a configured pstore_update_ms timer, and a subsequent crash that writes a larger buffer than the one initially allocated. These conditions make practical exploitation difficult, suggesting a low to moderate likelihood of real‑world attacks, though the memory corruption payload could grant privilege escalation or cause a system crash if successfully leveraged.

Generated by OpenCVE AI on June 5, 2026 at 07:52 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Upgrade the kernel to a version that contains the persistent_ram_save_old() fix, such as the latest stable release from your distribution or the upstream commit that adds safe buffer reallocation.
  • If an immediate kernel upgrade is not feasible, disable the pstore_update_ms timer by setting it to a negative value or otherwise preventing the periodic pstore work that triggers the overflow scenario.
  • Rebuild the kernel with the pstore/ram patch applied if your distribution does not yet provide a patched kernel version.

Generated by OpenCVE AI on June 5, 2026 at 07:52 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Tue, 09 Jun 2026 20:45:00 +0000

Type Values Removed Values Added
CPEs cpe:2.3:o:linux:linux_kernel:3.5:-:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:3.5:rc4:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:3.5:rc5:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:3.5:rc6:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:3.5:rc7:*:*:*:*:*:*

Fri, 05 Jun 2026 06:45:00 +0000

Type Values Removed Values Added
Metrics cvssV3_1

{'score': 5.5, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H'}

cvssV3_1

{'score': 7.8, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H'}


Thu, 04 Jun 2026 00:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-787
References
Metrics threat_severity

None

cvssV3_1

{'score': 5.5, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H'}

threat_severity

Moderate


Wed, 03 Jun 2026 17:45:00 +0000

Type Values Removed Values Added
Description In the Linux kernel, the following vulnerability has been resolved: pstore/ram: fix buffer overflow in persistent_ram_save_old() persistent_ram_save_old() can be called multiple times for the same persistent_ram_zone (e.g., via ramoops_pstore_read -> ramoops_get_next_prz for PSTORE_TYPE_DMESG records). Currently, the function only allocates prz->old_log when it is NULL, but it unconditionally updates prz->old_log_size to the current buffer size and then performs memcpy_fromio() using this new size. If the buffer size has grown since the first allocation (which can happen across different kernel boot cycles), this leads to: 1. A heap buffer overflow (OOB write) in the memcpy_fromio() calls 2. A subsequent OOB read when ramoops_pstore_read() accesses the buffer using the incorrect (larger) old_log_size The KASAN splat would look similar to: BUG: KASAN: slab-out-of-bounds in ramoops_pstore_read+0x... Read of size N at addr ... by task ... The conditions are likely extremely hard to hit: 0. Crash with a ramoops write of less-than-record-max-size bytes. 1. Reboot: ramoops registers, pstore_get_records(0) reads old crash, allocates old_log with size X 2. Crash handler registered, timer started (if pstore_update_ms >= 0) 3. Oops happens (non-fatal, system continues) 4. pstore_dump() writes oops via ramoops_pstore_write() size Y (>X) 5. pstore_new_entry = 1, pstore_timer_kick() called 6. System continues running (not a panic oops) 7. Timer fires after pstore_update_ms milliseconds 8. pstore_timefunc() → schedule_work() → pstore_dowork() → pstore_get_records(1) 9. ramoops_get_next_prz() → persistent_ram_save_old() 10. buffer_size() returns Y, but old_log is X bytes 11. Y > X: memcpy_fromio() overflows heap Requirements: - a prior crash record exists that did not fill the record size (almost impossible since the crash handler writes as much as it can possibly fit into the record, capped by max record size and the kmsg buffer almost always exceeds the max record size) - pstore_update_ms >= 0 (disabled by default) - Non-fatal oops (system survives) Free and reallocate the buffer when the new size differs from the previously allocated size. This ensures old_log always has sufficient space for the data being copied.
Title pstore/ram: fix buffer overflow in persistent_ram_save_old()
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-06-05T06:06:25.657Z

Reserved: 2026-05-13T15:03:33.107Z

Link: CVE-2026-46253

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Analyzed

Published: 2026-06-03T18:16:26.170

Modified: 2026-06-09T20:42:43.183

Link: CVE-2026-46253

cve-icon Redhat

Severity : Moderate

Publid Date: 2026-06-03T00:00:00Z

Links: CVE-2026-46253 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-06-05T08:00:19Z

Weaknesses