CVE-2026-80994 in Linux
要約
〜によって VulDB • 2026年09月12日
Linuxカーネルにおいて、以下の脆弱性が修正されました：
net: openvswitch: フロー削除時のフローマスクのuse-after-freeを修正する
Fixesタグ内のコミットにより、フローテーブルから削除された直後にflow->maskの解放がRCU（Read-Copy-Update）経由でスケジュールされるようになりました。しかし、ポインタはフロー構造体のまま残っており、同じRCUクリティカルセクションの間アクセス可能となります。これはovs_flow_free()においてovs_mutexを必要としないようにするために行われています。
ただし、CMD_DELの処理中にフローを削除する際、削除前にRCU読取りロックを取得しておらず、その後ovs_flow_cmd_fill_info()がflow->maskポインタを使用しています。RCU読取りロックは取得されていますが、その時点では遅すぎます。該当行のコメントには、このロックが形式的なもので実質的な目的を持たないことが認められています。
これにより、削除と情報の埋め込み処理の間にRCUグレース期間が経過するとuse-after-freeが発生します。競合状態（race condition）のウィンドウは短いです存在しますが、情報用のメモリ割り当てに少し時間がかかる場合、実際のクラッシュを引き起こす可能性があります：
BUG: KASAN: slab-use-after-free in __ovs_nla_put_key net/openvswitch/flow_netlink.c:1996 BUG: KASAN: slab-use-after-free in ovs_nla_put_key+0x2463/0x2e30 net/openvswitch/flow_netlink.c:2250 Read of size 4 at addr ffff88801ee89970 by task ovs_flow_del_ec/9487
Call Trace: <TASK> __ovs_nla_put_key net/openvswitch/flow_netlink.c:1996 ovs_nla_put_key+0x2463/0x2e30 net/openvswitch/flow_netlink.c:2250 ovs_flow_cmd_fill_info+0x420/0x9c0 net/openvswitch/datapath.c:930 ovs_flow_cmd_del+0x53a/0x970 net/openvswitch/datapath.c:1467 ... netlink_rcv_skb+0x156/0x420 net/netlink/af_netlink.c:2556 </TASK>
タスク 9487によって割り当てられました： mask_alloc net/openvswitch/flow_table.c:967 flow_mask_insert net/openvswitch/flow_table.c:1012 ovs_flow_tbl_insert+0xea2/0x1a90 net/openvswitch/flow_table.c:1084 ovs_flow_cmd_new+0x7e3/0xd90 net/openvswitch/datapath.c:1086 ... netlink_rcv_skb+0x156/0x420 net/netlink/af_netlink.c:2556
タスク 9485によって解放されました： rcu_free_sheaf+0x1e/0x100 mm/slub.c:5978 rcu_do_batch kernel/rcu/tree.c:2645 rcu_core+0x59c/0x10c0 kernel/rcu/tree.c:2897 handle_softirqs+0x1e4/0x9a0 kernel/softirq.c:622 ... instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1062
この競合状態を回避するため、ovs_flow_cmd_fill_info()の後にovs_flow_tbl_remove()が呼び出される必要があります。これにより、強制キャストと形式的なRCU読取りロックのクリーンアップにも役立ちます。Fixesタグ内のコミット以前は、フローオブジェクト自体が解放されない限り順序は問題ありませんでした。
より広範なRCUクリティカルセクションを使用することも別の選択肢ですが、GFP_KERNELによる割り当てが存在するため阻害されています。
Trend MicroのZero Day InitiativeによってZDI-CAN-32042として報告されました。
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.