CVE-2026-46253

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pstore/ram: fix buffer overflow in persistent_ram_save_old()<br /> <br /> persistent_ram_save_old() can be called multiple times for the same<br /> persistent_ram_zone (e.g., via ramoops_pstore_read -&gt; ramoops_get_next_prz<br /> for PSTORE_TYPE_DMESG records).<br /> <br /> Currently, the function only allocates prz-&gt;old_log when it is NULL,<br /> but it unconditionally updates prz-&gt;old_log_size to the current buffer<br /> size and then performs memcpy_fromio() using this new size. If the<br /> buffer size has grown since the first allocation (which can happen<br /> across different kernel boot cycles), this leads to:<br /> <br /> 1. A heap buffer overflow (OOB write) in the memcpy_fromio() calls<br /> 2. A subsequent OOB read when ramoops_pstore_read() accesses the buffer<br /> using the incorrect (larger) old_log_size<br /> <br /> The KASAN splat would look similar to:<br /> BUG: KASAN: slab-out-of-bounds in ramoops_pstore_read+0x...<br /> Read of size N at addr ... by task ...<br /> <br /> The conditions are likely extremely hard to hit:<br /> <br /> 0. Crash with a ramoops write of less-than-record-max-size bytes.<br /> 1. Reboot: ramoops registers, pstore_get_records(0) reads old crash,<br /> allocates old_log with size X<br /> 2. Crash handler registered, timer started (if pstore_update_ms &gt;= 0)<br /> 3. Oops happens (non-fatal, system continues)<br /> 4. pstore_dump() writes oops via ramoops_pstore_write() size Y (&gt;X)<br /> 5. pstore_new_entry = 1, pstore_timer_kick() called<br /> 6. System continues running (not a panic oops)<br /> 7. Timer fires after pstore_update_ms milliseconds<br /> 8. pstore_timefunc() → schedule_work() → pstore_dowork() → pstore_get_records(1)<br /> 9. ramoops_get_next_prz() → persistent_ram_save_old()<br /> 10. buffer_size() returns Y, but old_log is X bytes<br /> 11. Y &gt; X: memcpy_fromio() overflows heap<br /> <br /> Requirements:<br /> - a prior crash record exists that did not fill the record size<br /> (almost impossible since the crash handler writes as much as it<br /> can possibly fit into the record, capped by max record size and<br /> the kmsg buffer almost always exceeds the max record size)<br /> - pstore_update_ms &gt;= 0 (disabled by default)<br /> - Non-fatal oops (system survives)<br /> <br /> Free and reallocate the buffer when the new size differs from the<br /> previously allocated size. This ensures old_log always has sufficient<br /> space for the data being copied.