CVE-2023-52828 in Linux
要約
〜によって VulDB • 2026年05月20日
Linuxカーネルにおいて、以下の脆弱性が修正されました：
bpf: BPFプログラムの一環として IP == ksym.end を検出する
bpf_throw kfuncが、検証器内でnoreturnセマンティクスを持つ最初のそのような呼び出し命令となったため、これにより予期せぬ方法でデッドコード削除が有効化されます。具体的には、bpf_throw呼び出しに続く任意の命令は決して「参照済み」としてマークされません。さらに、呼び出しチェーンが最終的にスローする場合、呼び出し元の関数において、最終的にスローするサブプロシージャへの呼び出し命令に続く任意の命令も、決して「参照済み」としてマークされません。
これを修正するための誘惑的な方法は、プログラムのjited_lenを増加させる追加の'int3'命令を生成し、実行時にプログラムがスローした場合でも、bpf_throw（または常にスローするサブプロシージャ）への呼び出し命令がプログラムの最終命令として生成された場合でも、その境界を検出できるようにすることです。
このようなプログラムの例は以下の通りです：
do_something(): ... r0 = 0 exit
foo(): r1 = 0 call bpf_throw r0 = 0 exit
bar(cond): if r1 != 0 goto pc+2 call do_something exit call foo r0 = 0 // 検証器によって決して参照されない exit //
main(ctx): r1 = ... call bar r0 = 0 exit
ここで、実際にスローした場合、スタックトレースは以下のようになります：
bpf_throw foo bar main
bar関数では、生成される最終命令はfooへの呼び出しとなるため、戻りアドレスは後続の命令（x86ではJITによってint3として生成される）になります。これはプログラムのjited_lenの範囲外に位置することになり、そのため、アンワインディング時に、戻りアドレスがどのプログラムにも属さないものとして発見できず、決して期待しないBPFプログラムの信頼性の低いスタックアンワインディングによりパニックに至ります。
この問題を解決するために、bpf_prog_ksym_findが IP == ksym.end をBPFプログラムの一部として扱うようにし、is_bpf_text_addressがこのようなケースでtrueを返すようにします。これにより、最終命令が呼び出し命令となった場合でも、信頼性の高いアンワインディングが可能になります。
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.