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
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 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.
AvailableHarborGuard 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.
AvailableA 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.
AvailableExploit 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.
Fix available
- Linux / Linux< 58bda5a1d1ee98254383ef34f76b2c35140513ea (from 201e4aca5aa179e6c69a4dcd36a3562e56b8d670) · < 06d2c8bd108cea503f6f6e13e47495ed1085275f (from 201e4aca5aa179e6c69a4dcd36a3562e56b8d670) · < 2fa9a047c6a50ec80c3890dd623b85e237f0d1fd (from 201e4aca5aa179e6c69a4dcd36a3562e56b8d670) · < cff0ef043e16feb5a02307c8f9d0117a96c5587c (from 201e4aca5aa179e6c69a4dcd36a3562e56b8d670) · < 9a6fc69a570c0780834246d52c856cc3dbc2605f (from 201e4aca5aa179e6c69a4dcd36a3562e56b8d670) · < 4f73486ca822305c1cf5b8ebc0b53a6ab3801a81 (from 201e4aca5aa179e6c69a4dcd36a3562e56b8d670)
- Linux / Linux3.5Fixed 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:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H