CVE-2026-46253: Linux Kernel Buffer Overflow Vulnerability

CVE-2026-46253 Overview

CVE-2026-46253 is a heap buffer overflow vulnerability in the Linux kernel's pstore/ram subsystem. The flaw resides in persistent_ram_save_old(), which can be invoked multiple times for the same persistent_ram_zone through the ramoops_pstore_read → ramoops_get_next_prz call path for PSTORE_TYPE_DMESG records. The function allocates prz->old_log only when it is NULL but unconditionally updates prz->old_log_size to the current buffer size before calling memcpy_fromio(). When the buffer size grows between kernel boot cycles, the copy operation writes past the originally allocated heap region, producing both an out-of-bounds (OOB) write and a subsequent OOB read.

Critical Impact
A heap buffer overflow in the kernel ramoops persistent storage path can corrupt adjacent kernel heap memory and leak data through follow-on out-of-bounds reads.

Affected Products

Linux kernel (pstore/ram subsystem, fs/pstore/ram_core.c)
Distributions enabling CONFIG_PSTORE_RAM with ramoops configured
Systems running with pstore_update_ms >= 0 and ramoops persistent storage

Discovery Timeline

2026-06-03 - CVE-2026-46253 published to NVD
2026-06-03 - Last updated in NVD database

Technical Details for CVE-2026-46253

Vulnerability Analysis

The issue is a classic [CWE-122] heap-based buffer overflow combined with an out-of-bounds read. persistent_ram_save_old() is responsible for preserving a previously logged ramoops region into a kernel heap allocation referenced by prz->old_log. The function correctly allocates the buffer on first call, but treats prz->old_log_size as a mutable field that always reflects the live buffer_size() value. On a second invocation with a larger live size, the subsequent memcpy_fromio() copies more bytes than were ever allocated.

After the OOB write, ramoops_pstore_read() reads old_log_size bytes from old_log, producing an OOB read against the same undersized allocation. Both primitives operate in kernel context against the SLAB/SLUB heap, making this a kernel memory corruption issue rather than a userspace bug.

Root Cause

The root cause is a missing size-consistency check between the cached allocation length and the current ramoops zone buffer size. The original code allocated old_log lazily but never reallocated when sizes diverged across invocations. The fix frees and reallocates old_log whenever the new size differs from the previously allocated size, ensuring the destination buffer always matches the copy length.

Attack Vector

The advisory states that the trigger conditions are difficult to achieve in practice. Reproduction requires a prior crash record that did not fill the maximum record size, pstore_update_ms >= 0 (disabled by default), a non-fatal oops where the system continues running, and a subsequent timer-driven pstore_get_records(1) call that re-enters persistent_ram_save_old() with a larger buffer_size() than the prior allocation. When these conditions align, memcpy_fromio() writes Y bytes into an X-byte allocation where Y > X, corrupting adjacent slab objects.

No public exploit code is referenced for this CVE. The vulnerability is described in prose only — see the upstream commits listed under Patch Information for the corrected logic.

Detection Methods for CVE-2026-46253

Indicators of Compromise

KASAN reports of the form BUG: KASAN: slab-out-of-bounds in ramoops_pstore_read+0x... indicating an OOB read against the ramoops old-log buffer.
Unexpected kernel slab corruption warnings or SLUB redzone violations occurring shortly after ramoops record reads.
Kernel oops or panic traces referencing persistent_ram_save_old or memcpy_fromio in the fs/pstore/ram_core.c call path.

Detection Strategies

Enable KASAN on test and pre-production kernels to surface the OOB write and read primitives during ramoops record processing.
Audit kernel build configurations for CONFIG_PSTORE_RAM=y and non-default pstore_update_ms values that increase exposure.
Correlate ramoops record sizes across reboots to identify zones whose buffer_size() grows over time.

Monitoring Recommendations

Collect and centralize dmesg output from Linux fleets and alert on KASAN slab-out-of-bounds events tied to pstore symbols.
Track kernel package versions against the fix commits to confirm patched builds are deployed.
Monitor systems that enable ramoops on persistent DRAM or reserved memory regions, where the conditions for triggering this flaw are more likely.

How to Mitigate CVE-2026-46253

Immediate Actions Required

Upgrade to a Linux kernel build that includes the upstream fix for persistent_ram_save_old() referenced in the kernel.org commits below.
Verify that pstore_update_ms is left at its default disabled value on production systems that do not require timer-driven pstore polling.
Rebuild and redeploy any custom kernel images that backport ramoops support without the size-reallocation fix.

Patch Information

The vulnerability is resolved by freeing and reallocating prz->old_log whenever the new buffer size differs from the previously allocated size. The fix is distributed across the following stable tree commits:

Workarounds

Leave pstore_update_ms at its default (disabled) value to avoid the timer-driven re-read path that exercises persistent_ram_save_old() on a running system.
Disable CONFIG_PSTORE_RAM on systems that do not rely on ramoops for crash log persistence until a patched kernel is deployed.
Avoid changing the configured ramoops record sizes across reboots, since a smaller-to-larger size transition is required to reach the overflow.

bash

# Configuration example: confirm pstore_update_ms is disabled
cat /sys/module/pstore/parameters/update_ms
# Expected output: -1 (timer disabled)

# Verify ramoops configuration in current kernel
zcat /proc/config.gz | grep -E 'CONFIG_PSTORE_RAM|CONFIG_PSTORE='

# Check running kernel version against patched stable releases
uname -r