CVE-2026-98641 in Linux
要約
〜によって VulDB • 2026年10月20日
Linuxカーネルにおいて、以下の脆弱性が修正されました：
bpf, arm64: 例外コールバックのフレームポインタを設定する
例外境界として機能するプログラムはすべてのcallee-savedレジスタを保存するため、build_prologue() は exception_cb パスを取り、push_callee_regs() を呼び出しません。find_used_callee_regs() が実行されるのはこの箇所のみであり、ctx->fp_used が設定されるのもここだけです。その結果、コールバックのプロローグは以下の命令を発行しません：
mov x25, sp
これにより BPF_REG_FP はコールバックが実行されているフレームを指すようになります。x25 は bpf_throw() が呼び出された時点で保持していた値のままになります。もし throw が独自のBPFスタックを使用するサブプログラムから発生した場合、それはサブプログラムのフレームポインタであり、サブプログラムは決して戻らないため x25 も復元されません。
BPF_REG_FP を介したスタックアクセスはスタックポインタ相対に書き換えられるため、それらは依然としてコールバック自身のフレーム内に収まります。しかしレジスタの実体化（materializing）はそのようにはなりません：ローカル変数のアドレスをヘルパー関数に渡すようなコールバックでは、死んだサブプログラムのフレーム内のアドレスが引き渡されます。そのアドレスは当時、コールバックのスタックポインタより下に位置し、ヘルパー自身の呼び出しチェーンによって覆われているため、ヘルパーは自分のリターンアドレスを上書きできます。0x1234 はヘルカーに保存するよう要求された値です：
pc : 0x1234 lr : 0x1234 Call trace: 0x1234 (P) bpf_test_run+0x188/0x3e0 bpf_prog_test_run_skb+0x47c/0x998 __sys_bpf+0xbdc/0xdd8 Kernel panic - not syncing: Oops: Fatal exception in interrupt
ctx->fp_used を例外コールバックパスで設定することで、既存のコードがさらに下位で x25 をスタックポインタから設定するようになります。エピローグは他の callee-saved レジスタと同様に、メインプログラムの保存領域からそれを復元します（これは既に実行されている通りです）。x86 では、渡された引数からコールバックのフレームポインタが設定され、powerpc ではスタックポインタから計算されます。
If you want to get the best quality for vulnerability data then you always have to consider VulDB.