CVE-2026-46253

What it actually does

This is a local Linux kernel memory-corruption flaw in the pstore/ram ramoops path. persistent_ram_save_old() may reuse an existing old_log allocation while updating old_log_size to a larger current persistent RAM buffer size, causing memcpy_fromio() to write past the heap allocation and later allowing ramoops_pstore_read() to read past it. In the right conditions, this can corrupt kernel heap memory, expose adjacent kernel memory, crash the system, or potentially support local privilege escalation. The trigger conditions are unusually specific: a prior undersized ramoops crash record, pstore_update_ms enabled, a surviving non-fatal oops that writes a larger record, and a later pstore refresh path that rereads the record.

Why it matters to the business

Systems using Linux kernel pstore/ram or ramoops for persistent crash logging could be exposed to kernel instability or, in a worst case, local privilege escalation by a user or process already able to run code locally and trigger kernel oops conditions. Operational impact is most relevant for embedded, appliance, mobile, and server environments that enable ramoops/pstore for post-crash diagnostics. Public exploitation is not currently indicated, the EPSS score is very low, and the issue is not in CISA KEV, but kernel memory-corruption bugs should still be addressed through normal kernel update cycles because successful exploitation can affect confidentiality, integrity, and availability of the host.

How an attack unfolds

An attacker first needs local execution on a system using the Linux kernel pstore/ram ramoops backend. The system must already contain a prior persistent crash record smaller than the later record size, and periodic pstore updates must be enabled through pstore_update_ms. The attacker then causes a non-fatal kernel oops or otherwise reaches a condition where the system survives and writes a larger ramoops record. When the pstore workqueue later rereads persistent records, persistent_ram_save_old() may keep the old smaller heap allocation but update the size metadata to the larger record size. The subsequent memcpy_fromio() copies the larger amount of data into the smaller heap buffer, producing a kernel heap out-of-bounds write. Later reads through ramoops_pstore_read() may also perform an out-of-bounds read. Reliable exploitation would require shaping kernel heap state and the pstore record sequence, so denial of service is the most straightforward impact; privilege escalation or information disclosure may be possible in theory depending on kernel configuration, mitigations, and heap layout.

How to fix it

Apply a kernel update from the relevant Linux distribution, device vendor, or kernel maintainer that includes the pstore/ram fix for persistent_ram_save_old(), specifically the change that frees and reallocates old_log when the persistent RAM buffer size changes. No exact fixed package versions were provided in the input, so remediation should be tracked through vendor advisories for the deployed kernel streams. Where immediate patching is not possible, reduce exposure by disabling unused pstore/ram or ramoops functionality, leaving pstore_update_ms disabled where feasible, restricting local shell/code execution, and limiting the ability of untrusted users or workloads to trigger kernel oops conditions. Mitigations do not replace patching because this is kernel memory corruption.

How to confirm the fix worked

Confirm the running kernel package or build includes the upstream/vendor pstore/ram fix for persistent_ram_save_old(). Validate through distribution package metadata, kernel changelogs, or source inspection showing that old_log is reallocated when the saved buffer size changes. Check runtime exposure by reviewing whether pstore/ram or ramoops is configured, whether /sys/fs/pstore is mounted/populated, whether ramoops parameters are present in the kernel command line or device tree, and whether pstore_update_ms is enabled. After remediation, verify the system is booted into the updated kernel, not merely that the package is installed. For source-based validation, confirm persistent_ram_save_old() does not retain a smaller old_log allocation when buffer_size() changes.

Typical attack path

1. Gain local code execution or access to a local account on a Linux system where pstore/ram ramoops is configured.
2. Confirm or rely on ramoops/pstore being active and pstore_update_ms being enabled so persistent records are periodically refreshed.
3. Ensure a prior persistent crash/oops record exists that is smaller than a later record size.
4. Trigger a non-fatal kernel oops or other condition that writes a larger ramoops record while the system continues running.
5. Wait for the pstore timer/workqueue path to call pstore_get_records(), ramoops_get_next_prz(), and persistent_ram_save_old().
6. Cause the stale smaller old_log allocation to be reused while old_log_size is updated to the larger size.
7. Leverage the resulting kernel heap out-of-bounds write/read to crash the kernel, disclose memory, or attempt local privilege escalation.

How to detect it

Look for evidence of attempted or accidental triggering in kernel logs, persistent pstore records, crash logs, and EDR telemetry that captures kernel panic/oops output. Useful sources include journalctl -k, /var/log/kern.log, /var/log/messages, dmesg output, /sys/fs/pstore contents, crash dump infrastructure, and KASAN/KFENCE reports on debug kernels. Search for slab-out-of-bounds reports involving ramoops_pstore_read(), persistent_ram_save_old(), memcpy_fromio(), persistent_ram, pstore_get_records(), or ramoops_get_next_prz(). Also review boot parameters and sysfs values for exposure indicators such as ramoops configuration and pstore_update_ms being non-negative. Because this issue has highly specific trigger conditions and no known public exploitation or KEV listing, detection will often identify crashes or sanitizer findings rather than definitive malicious exploitation. Investigate local user activity, recent kernel oops causes, and processes active immediately before matching kernel memory-corruption logs.

• BUG: KASAN: slab-out-of-bounds in ramoops_pstore_read
• slab-out-of-bounds in ramoops_pstore_read
• persistent_ram_save_old
• ramoops_pstore_read
• ramoops_get_next_prz
• pstore_get_records
• pstore_dowork
• pstore_timefunc
• pstore_timer_kick
• memcpy_fromio
• pstore_update_ms
• /sys/fs/pstore
• ramoops
• pstore/ram
• persistent_ram
• old_log_size

What your security team should do

• Inventory Linux systems that enable pstore/ram, ramoops, or persistent crash logging, prioritizing embedded devices, appliances, mobile-derived platforms, and hosts with local multi-user or workload execution.
• Patch affected kernels through the normal emergency/standard kernel maintenance process according to local risk, prioritizing systems where untrusted users or containers can execute code locally.
• If patching is delayed, disable unused ramoops/pstore functionality or keep pstore_update_ms disabled where operationally acceptable.
• Monitor for kernel oops, KASAN, slab-out-of-bounds, and pstore/ram errors on systems with ramoops enabled.
• Restrict local access and harden workload isolation because exploitation requires local execution and precise kernel state manipulation.
• Track vendor advisories for exact fixed kernel package versions, since no fixed versions were supplied in the input.
• Treat any unexplained kernel crash on an exposed system as potentially security-relevant until logs and crash records are reviewed.