CVE-2026-46253: Linux Kernel pstore/ramoops Buffer Overflow Privilege Escalation

Technical summary

The vulnerability exists in persistent_ram_save_old(), called during pstore record reading. The function allocates prz->old_log only when it is NULL but unconditionally updates prz->old_log_size to the current buffer_size(). If the buffer grows between invocations—possible across kernel boot cycles or during the same runtime—a subsequent memcpy_fromio() will attempt to copy more data than the previously allocated buffer can hold, resulting in a heap-based buffer overflow (CWE-787). The KASAN memory sanitizer would detect this as a slab-out-of-bounds condition. Additionally, the incorrect old_log_size causes out-of-bounds reads when ramoops_pstore_read() later accesses the buffer. The fix reallocates the buffer when the new size differs from the previously allocated size, ensuring sufficient capacity.

Business impact

Organizations running systems with pstore/ramoops enabled (particularly edge devices, IoT platforms, and systems requiring persistent crash logging) face a localized privilege escalation risk. Successful exploitation allows an unprivileged local process to corrupt kernel memory, potentially leading to denial of service or privilege escalation to root. The blast radius is limited by the requirement for prior crash conditions and a running pstore timer, but systems relying on ramoops for firmware or kernel diagnostics are directly affected. The impact on cloud infrastructure is minimal unless host systems have ramoops configured, but bare-metal and embedded deployments should treat this as a meaningful security concern.

Affected systems

The Linux kernel is affected across multiple versions where pstore/ramoops functionality is enabled. The vulnerability specifically impacts systems configured with ramoops persistence (common on ARM, embedded, and some enterprise platforms). Systems with pstore_update_ms set to a non-negative value are at higher risk, as this enables the background timer that triggers the vulnerable code path. Standard server deployments with ramoops disabled are unaffected. The vulnerability requires local access to the compromised system, making remote exploitation infeasible.

Exploitability

Exploitation requires a specific precondition sequence that is 'extremely hard to hit,' per the advisory: a prior partial crash record (undersized), pstore timer enabled, a surviving non-fatal oops, and precise timing for the background recovery job to run before cleanup occurs. The prerequisites are so restrictive that accidental triggering in production is unlikely. However, a sophisticated local attacker with detailed kernel internals knowledge could theoretically craft conditions to trigger the overflow. The requirement for local code execution significantly constrains the threat model. CVSS 7.8 (HIGH, AV:Local, AC:Low, PR:Low) reflects the local privilege escalation potential despite difficult trigger conditions.

Remediation

Apply a kernel update that includes the fix to persistent_ram_save_old(). The patch reallocates prz->old_log when the new buffer size differs from the previously allocated size, eliminating the overflow condition. Verify the fix has been merged into your kernel branch and applied to production systems. As an interim control, systems can disable pstore/ramoops if crash preservation is not operationally necessary, or set pstore_update_ms to a negative value to disable the background timer and prevent the vulnerable code path from being invoked.

Patch guidance

Monitor your Linux distribution's security advisories for kernel updates addressing CVE-2026-46253. The fix is in the pstore subsystem (likely in fs/pstore/ram.c). Verify the patch is present in your kernel version by checking the commit history or release notes. For custom kernels, cherry-pick the fix from the stable kernel repository. Testing should confirm that ramoops still functions correctly and that crash logs are properly preserved after patching. Prioritize patching systems where ramoops is actively configured and pstore_update_ms is enabled.

Detection guidance

Monitor system logs for KASAN splats or memory corruption warnings related to ramoops_pstore_read() and persistent_ram_save_old(). Enable kernel address sanitizer (KASAN) on test systems to detect the out-of-bounds access. In production, watch for unexpected kernel panics or memory corruption signatures (heap corruption messages, invalid pointer dereferences in pstore code paths). Monitor dmesg for ramoops-related errors or warnings indicating buffer size mismatches. Systems with CONFIG_KASAN enabled will immediately surface exploitation attempts as BUG reports.

Why prioritize this

Prioritize patching systems where pstore/ramoops is enabled and pstore_update_ms is set to a non-negative value. Embedded systems, IoT devices, and edge computing platforms using ramoops for persistent diagnostics should be prioritized. Enterprise servers with disabled ramoops can defer patching. The HIGH CVSS score and local privilege escalation potential warrant timely remediation for affected systems, particularly in multi-tenant or high-security environments where unprivileged users have local access.

Risk score, explained

CVSS 7.8 reflects the seriousness of the memory corruption (high impact on confidentiality, integrity, and availability) but is moderated by the local-only attack vector and the extremely difficult precondition sequence required to trigger the vulnerability. The low complexity (AC:L) indicates that once conditions align, exploitation is straightforward, but Low Privilege requirement means an unprivileged account suffices. The vulnerability is not known to be widely exploited and has not been added to the CISA KEV catalog, indicating limited real-world active exploitation at the time of publication.

Frequently asked questions