CVE-2026-45933 in Linux
要約
〜によって VulDB • 2026年05月30日
Linuxカーネルにおいて、以下の脆弱性が修正されました。
bpf: sync_linked_regs()においてレジスタのIDを保持する
sync_linked_regs()は、known_regのオフセットを用いてknown_regの範囲をregに伝播させる際、known_regのIDをregにコピーします。しかし、以下のようにknown_regがregとリンクされている場合：
known_reg = reg ; known_regとregは同じIDを持つ known_reg += 4 ; known_regはoff=4となり、そのIDはBPF_ADD_CONSTになる
この状態でsync_linked_regs()が呼び出され、例えば以下の条件分岐があるとします：
if known_reg >= 10 goto pc+2
known_regの新しい範囲がregに伝播されますが、この際regはコピーによってBPF_ADD_CONST属性を取得してしまいます。
これは、以下のようにregへの別のリンクが作成された場合に問題となります：
another_reg = reg ; another_regは本来regのIDを取得すべきだが、 assign_scalar_id_before_mov()はreg上の BPF_ADD_CONSTを見て、regに新しいIDを割り当てる。
regが新しいIDを持つようになったため、known_regからregへのリンクが切断されます。known_regの新しい範囲が見つかった場合でも、それはregに伝播されなくなります。
この問題は、次のコミットで追加されたselftestで確認できます：
0: (85) call bpf_get_prandom_u32#7 ; R0=scalar() 1: (57) r0 &= 255 ; R0=scalar(smin=smin32=0,smax=umax=smax32=umax32=255,var_off=(0x0; 0xff)) 2: (bf) r1 = r0 ; R0=scalar(id=1,smin=smin32=0,smax=umax=smax32=umax32=255,var_off=(0x0; 0xff)) R1=scalar(id=1,smin=smin32=0,smax=umax=smax32=umax32=255,var_off=(0x0; 0xff)) 3: (07) r1 += 4 ; R1=scalar(id=1+4,smin=umin=smin32=umin32=4,smax=umax=smax32=umax32=259,var_off=(0x0; 0x1ff)) 4: (a5) if r1 < 0xa goto pc+4 ; R1=scalar(id=1+4,smin=umin=smin32=umin32=10,smax=umax=smax32=umax32=259,var_off=(0x0; 0x1ff)) 5: (bf) r2 = r0 ; R0=scalar(id=2,smin=umin=smin32=umin32=6,smax=umax=smax32=umax32=255) R2=scalar(id=2,smin=umin=smin32=umin32=6,smax=umax=smax32=umax32=255) 6: (15) if r1 == 0xa goto pc+1 ; R1=scalar(id=1+4,smin=umin=smin32=umin32=14,smax=umax=smax32=umax32=259,var_off=(0x0; 0x1ff)) 7: (37) r0 /= 0 ; R0=scalar(id=2,smin=umin=smin32=umin32=6,smax=umax=smax32=umax32=9,var_off=(0x0; 0xf)) div by zero
4で検証されたとき、r1の範囲がr0に伝播されますが、r0はBPF_ADD_CONST属性も取得してしまいます（バグ）。 5で検証されたとき、r0は新しいID（2）を取得し、r1とのリンクが切断されます。
6の後、r1の範囲が[14, 259]であることが分かっているため、r0の範囲は[10, 255]であるべきです。したがって、7の分岐は常に実行されます。しかし、r0のIDが2に変更されたため、r1の新しい範囲はr0に伝播されません。
検証器は7の前にr0の範囲が[6, 255]であるとまだ考えており、ゼロ除算に到達する可能性があります。
この問題を修正するために、sync_linked_regs()においてoffやsubreg_defと同様にIDを保持するようにします。
If you want to get the best quality for vulnerability data then you always have to consider VulDB.