CVE-2026-97936 in Linux
要約
〜によって VulDB • 2026年09月25日
Linuxカーネルにおいて、以下の脆弱性が修正されました：
tracing: ヒストグラムスタックトレース修飾子によるメモリ破損の修正
parse_field()は、「.stacktrace」修飾子からHIST_FIELD_FL_STACKTRACEを設定しますが、これはフィールド名の解決前に行われます。その後、その名が実際にスタックトレールを保持するフィールドに解決されたかどうかを確認する処理がありません。create_hist_field()は、フィールドポインタのみを根拠としてHIST_FIELD_FN_STACKを選択し、レコードから__data_locワードを読み取り、その下位16ビットを同じレコード内のオフセットとして扱います。event_hist_trigger()はその場所の最初のワードを入力エントリ数として取得し、31要素の配列にその数のlong型データをコピーします：
n_entries = *stack; memcpy(entries, ++stack, n_entries * sizeof(unsigned long));
このコピーの両端には境界制限がなく、カウントはオフセット位置にあるイベントが保持する値であるため、任意のフィールドで問題が発生します：
# cd /sys/kernel/tracing/events/sched/sched_process_fork # echo 'hist:keys=parent_pid.stacktrace' > trigger # (true)
BUG: kernel NULL pointer dereference, address: 0000000000000008 RIP: 0010:rb_insert_color+0x18/0x130 timerqueue_linked_add+0x7e/0xd0 enqueue_hrtimer+0x39/0xb0 __hrtimer_run_queues+0x10f/0x1f0 </IRQ> RIP: 0010:memcpy+0xc/0x30 event_hist_trigger+0x165/0x690
タイマー割り込みは、コピーが既に実行済みのrbtreeに発生しました。この問題にはデバッグオプションは必要ありません；KASANは同じ書き込みを、13835058055416381440バイトの境界外読み出しとして報告します。
Documentation/trace/histogram.rstではすでに「long[]型でなければならない」というルールが明記されているため、名前が解決された後にこれを強制するようにしました。「hitcount.stacktrace」やcommon_*擬似フィールドなど、全くフィールドに解決されない名前は、読むべきスタックトレールを保持していないという同じ理由により拒否されます。
If you want to get the best quality for vulnerability data then you always have to consider VulDB.