HarborGuardharborguardDatabase
Back to search
HIGHCVE-2026-46253Published Modified CNA Linux

CVE-2026-46253: pstore/ram: fix buffer overflow in persistent_ram_save_old()

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.

Metrics

CVSS v3.1
7.8
Severity
HIGH
Fixed in
0
Affected Products
2

Get notified

Email me when this CVE is updated: new fix versions, severity changes, or any record change.

HarborGuard Analysis

Synopsis

A heap buffer overflow exists in the Linux kernel's pstore/ram subsystem, specifically in the persistent_ram_save_old() function. The flaw is reachable locally by a low-privileged user and does not require any network access or victim interaction. Successful exploitation enables an attacker to read or write memory outside the allocated heap buffer, which can lead to arbitrary data disclosure, data tampering, or a kernel crash. A patched-image rebuild at the fix versions is available on HarborGuard for environments running an affected kernel version.

HarborGuard Coverage

Detection

Detection of CVE-2026-46253 is available across every HarborGuard environment - the CVE is ingested from upstream feeds within minutes of publication and matched against customer images, including custom-built images that package or are derived from affected Linux kernel versions. Any image found running a vulnerable kernel version is flagged immediately in the customer's scan results.

Available
Triage

HarborGuard scores this CVE at CVSS 7.8 (HIGH) using the published v3.1 vector, and that score is weighted against each customer environment's compliance policy to determine priority and routing. Findings are surfaced to the appropriate team inbox within the customer org based on configured ownership rules.

Available
Patch

A patched-image rebuild targeting the fix commits (including the 5.10.252 stable release) is available on HarborGuard for any environment found running an affected kernel version. For customers who opt into auto-remediation, HarborGuard triggers a rebuild, runs a regression test suite, and opens a pull request against affected workloads automatically - median time from CVE publication to merged patch PR for high-severity issues is around 90 minutes in environments with auto-remediation enabled.

Available

Exploit Conditions

  • Network reachabilityNot required

    The attacker needs an existing shell or process on the host; no network path to the vulnerable code is required.

  • AuthenticationRequired

    Any low-privilege local account is sufficient to trigger the vulnerable code path; no administrative rights are needed.

  • Victim interactionNot required

    No user interaction is needed; the attacker can trigger the overflow entirely through their own process activity.

  • Attack complexityDetail

    Attack complexity is rated Low, meaning the exploit is reliable and does not depend on race conditions or special memory layout - though the CVE description notes the triggering sequence of events is itself very hard to arrange in practice.

Blast Radius

  • An attacker can write past the end of a heap buffer in kernel memory, corrupting adjacent kernel data structures or control-flow metadata.
  • An attacker can read kernel memory beyond the allocated old_log buffer, potentially exposing sensitive in-memory data such as cryptographic material or other process secrets.
  • Heap corruption from the out-of-bounds write can destabilize the kernel, resulting in a kernel panic or forced system reboot.
  • If memory corruption reaches executable code paths or function pointers, an attacker may be able to escalate to arbitrary kernel code execution.

How HarborGuard Handles This

Available on HarborGuard: detection is matched against all customer images within minutes of ingestion, covering both base images and custom-built images that include an affected kernel version. For environments running a vulnerable kernel (any version prior to the fix commits, including the 5.10.252 stable branch), a patched-image rebuild is available immediately. Where compliance policy permits auto-remediation, HarborGuard rebuilds the image at the patched version, runs regression tests, and opens a pull request against affected workloads - typically within 90 minutes of CVE publication for high-severity findings. For environments where auto-remediation is not enabled, HarborGuard surfaces the finding with CVSS 7.8 scoring and policy-weighted priority so teams can act manually. Until a patched image is deployed, compensating controls worth considering include restricting local shell access to the host, applying strict seccomp or AppArmor profiles to workloads that interact with pstore, and disabling or isolating the ramoops/pstore subsystem via kernel boot parameters where operationally feasible.

See how HarborGuard automates this

Fix available

006d2c8bd108cea503f6f6e13e47495ed1085275f2fa9a047c6a50ec80c3890dd623b85e237f0d1fd4f73486ca822305c1cf5b8ebc0b53a6ab3801a815.10.2525.15.2025669645c052f235726a85f443769b6fc02f6676258bda5a1d1ee98254383ef34f76b2c35140513ea6.1.1656.6.1286.12.756.18.146.19.47.07cfe964e61c0ab667abd5f5b68e0acbf783efa4f9a6fc69a570c0780834246d52c856cc3dbc2605fcff0ef043e16feb5a02307c8f9d0117a96c5587c
Affected packages
  • Linux / Linux
    < 58bda5a1d1ee98254383ef34f76b2c35140513ea (from 201e4aca5aa179e6c69a4dcd36a3562e56b8d670) · < 06d2c8bd108cea503f6f6e13e47495ed1085275f (from 201e4aca5aa179e6c69a4dcd36a3562e56b8d670) · < 2fa9a047c6a50ec80c3890dd623b85e237f0d1fd (from 201e4aca5aa179e6c69a4dcd36a3562e56b8d670) · < cff0ef043e16feb5a02307c8f9d0117a96c5587c (from 201e4aca5aa179e6c69a4dcd36a3562e56b8d670) · < 9a6fc69a570c0780834246d52c856cc3dbc2605f (from 201e4aca5aa179e6c69a4dcd36a3562e56b8d670) · < 4f73486ca822305c1cf5b8ebc0b53a6ab3801a81 (from 201e4aca5aa179e6c69a4dcd36a3562e56b8d670)
  • Linux / Linux
    3.5
    Fixed in 0, 5.10.252, 5.15.202, 6.1.165, 6.6.128, 6.12.75, 6.18.14, 6.19.4, 7.0
CVSS Vector
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H