製品・ソフトウェアに関する情報
LinuxのLinux Kernelにおける境界外書き込みに関する脆弱性
Title LinuxのLinux Kernelにおける境界外書き込みに関する脆弱性
Summary

Linuxカーネルにおいて、以下の脆弱性が修正されました。pstore/ramのpersistent_ram_save_old()関数におけるバッファオーバーフローの修正です。persistent_ram_save_old()は、同じpersistent_ram_zoneに対して複数回呼び出される可能性があります(例: ramoops_pstore_readからramoops_get_next_prz経由でPSTORE_TYPE_DMESGレコードに対して呼び出されます)。現在、この関数はprz-old_logがNULLの場合にのみメモリを割り当てますが、prz-old_log_sizeは無条件に現在のバッファサイズに更新され、その新しいサイズを使ってmemcpy_fromio()を実行します。バッファサイズが最初の割り当て時から増加している場合(異なるカーネル起動サイクル間で発生する可能性があります)、次の問題が発生します。1. memcpy_fromio()呼び出しでのヒープバッファオーバーフロー(境界外書き込み)が起こります。2. ramoops_pstore_read()が不正な(より大きい)old_log_sizeを使ってバッファにアクセスし、境界外読み取りが発生します。KASANエラーは以下のように表示されます。BUG: KASAN: slab-out-of-bounds in ramoops_pstore_read+0x... Read of size N at addr ... by task ... 発生条件は極めて厳しいと考えられています。0. 最大レコードサイズ未満のバイト数のramoops書き込みによるクラッシュがあります。1. 再起動し、ramoopsが登録され、pstore_get_records(0)が古いクラッシュを読み取り、サイズXのold_logを割り当てます。2. クラッシュハンドラが登録され、タイマーが開始されます(pstore_update_ms = 0の場合)。3. 致命的でないOopsが発生し(システムは継続動作します)。4. pstore_dump()がramoops_pstore_write()経由でサイズY(X)のOopsを書き込みます。5. pstore_new_entryが1となり、pstore_timer_kick()が呼ばれます。6. システムはパニックを起こさず継続動作します。7. pstore_update_msミリ秒後にタイマーが起動します。8. pstore_timefunc() → schedule_work() → pstore_dowork() → pstore_get_records(1)の順に呼ばれます。9. ramoops_get_next_prz() → persistent_ram_save_old()が呼ばれます。10. buffer_size()はYを返しますが、old_logはXバイトのままです。11. Y Xによりmemcpy_fromio()でヒープオーバーフローが発生します。必要条件は以下の通りです。- 以前にレコードサイズを満たしていないクラッシュレコードが存在すること(クラッシュハンドラはほぼ常に最大レコードサイズおよびkmsgバッファ上限まで書き込むため、ほぼ不可能です)。- pstore_update_ms = 0(デフォルトは無効です)。- 致命的でないOops(システムが生き残る)。新しいサイズが以前に割り当てたサイズと異なる場合、バッファを解放し再割り当てすることでold_logが常にコピーされるデータに十分な領域を持つように保証します。

Possible impacts ・当該ソフトウェアが扱う全ての情報が外部に漏れる可能性があります。 ・当該ソフトウェアが扱う全ての情報が書き換えられる可能性があります。 ・当該ソフトウェアが完全に停止する可能性があります。 
Solution

リリース情報、またはパッチ情報が公開されています。参考情報を参照して適切な対策を実施してください。

Publication Date June 3, 2026, midnight
Registration Date June 10, 2026, 2:26 p.m.
Last Update June 10, 2026, 2:26 p.m.
CVSS3.0 : 重要
Score 7.8
Vector CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Affected System
Linux
Linux Kernel 3.5
Linux Kernel 3.5.1 以上 5.10.252 未満
Linux Kernel 5.11 以上 5.15.202 未満
Linux Kernel 5.16 以上 6.1.165 未満
Linux Kernel 6.13 以上 6.18.14 未満
Linux Kernel 6.19 以上 6.19.4 未満
Linux Kernel 6.2 以上 6.6.128 未満
Linux Kernel 6.7 以上 6.12.75 未満
CVE (情報セキュリティ 共通脆弱性識別子)
CWE (共通脆弱性タイプ一覧)
その他
Change Log
No Changed Details Date of change
1 [2026年06月10日]
  掲載
June 10, 2026, 2:26 p.m.

NVD Vulnerability Information
CVE-2026-46253
Summary

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.

Publication Date June 4, 2026, 3:16 a.m.
Registration Date June 4, 2026, 4:17 a.m.
Last Update June 5, 2026, 4:16 p.m.
Related information, measures and tools
Common Vulnerabilities List