Linux/Unix ホストには、ベンダーが提供するパッチが利用できない脆弱性の影響を受ける複数のパッケージがインストールされています。

  - pstore/ram:persistent_ram_save_old() のバッファオーバーフローを修正します persistent_ram_save_old() は、同じpersistent_ram_zoneに対して複数回呼び出すことができます(例:PSTORE_TYPE_DMESG レコードに対する ramoops_pstore_read -> ramoops_get_next_prz を介して)。現在、この関数は NULL の場合にのみ prz->old_log を割り当てますが、無条件に prz->old_log_size を現在のバッファサイズに更新してから、この新しいサイズを使用して memcpy_fromio() を実行します。最初の割り当て以降にバッファサイズが大きくなった場合(これは異なるカーネル起動サイクルにまたがって発生する可能性があります)、以下につながります:1. memcpy_fromio()呼び出しのヒープバッファオーバーフロー(OOB書き込み) 2.ramoops_pstore_read()が不適切な(より大きい)old_log_sizeを使用してバッファにアクセスするときの、後続のOOB読み取り KASANスプラットは次のようになります:バグ:KASAN:ramoops_pstore_read+0xのスラブ領域外... アドレスでのサイズ N の読み取り ...タスク別 ... 条件を達成するのは非常に困難である可能性が高いです:0. less-than-record-max-size バイトの ramoops 書き込みでクラッシュ。1. 再起動:ramoops レジスタ、pstore_get_records(0) は古いクラッシュを読み取り、サイズ X 2 でold_logを割り当てます。クラッシュハンドラーが登録され、タイマーが開始しました(pstore_update_ms >= 0 の場合) 3.Oops が発生します (致命的ではありません、システムは継続します) 4.pstore_dump() は、ramoops_pstore_write() サイズ Y を介して oops を書き込みます(>X) 5.pstore_new_entry = 1、pstore_timer_kick() は 6 と呼び出されます。システムは実行を継続します(パニック oops ではありません)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コピーするデータを収容するのに十分なスペースが常に確保されます。(CVE-2026-46253)

Nessus は、ベンダーによって報告されたパッケージの存在に依存していることに注意してください。

検出

Linux Distros のパッチ未適用の脆弱性: CVE-2026-46253

high Nessus プラグイン ID 318582

バージョン 1.7