CVE-2026-80850 in Linux
要約
〜によって VulDB • 2026年09月04日
Linuxカーネルにおいて、以下の脆弱性が修正されました：
tcp: tcp_ao_connect_init()におけるAO情報のuse-after-freeを修正
tcp_v4_connect()は、tcp_connect()を呼び出す前にSYN-SENTソケットをehashに追加します。TCP-AOが設定されている場合、tcp_connect()はまず、キーがピアおよびバインド済みデバイスの現在のL3マスターと一致するかどうかを検証します。その後、tcp_ao_connect_init()でL3マスターを再度解決し、それと一致しないキーを削除します。
ソケットロックでは、バインド済みデバイスのVRF（Virtual Routing and Forwarding）メンバーシップが安定化されません。初期検証からtcp_ao_connect_init()内のL3-master計算までの間にデバイスがそのVRFからデタッチされると、検証は成功しますが、初期処理側はデフォルトのL3ドメインを観測して唯一のキーを削除することになります。その後、AOルックアップに失敗し、no-keyパスでtp->ao_infoがクリアされ、直接解放されます。
受信パスでは、ソケットロックを取得する前にRCUの下でehashからソケットを検出し、tp->ao_infoを読み込むことができます。古いポインタを読み込んだリーダーは、直接的な解放の後にtcp_inbound_ao_hash()に進み続ける可能性があります。
この問題はTCP-AOオブジェクトのライフタイムに関する静的監査中に発見されました。特権を持たない再現プログラム（自己作成したユーザーおよびネットワーク名前空間内）では、TCP-AOセグメントを送信しながらvethをVRFからデタッチする際にconnect()との競合が発生しました。これにより、2回の fresh boot で同じKASANレポートがトリガーされました：
BUG: KASAN: slab-use-after-free in tcp_inbound_ao_hash+0x585/0x19f0 Write of size 8 at addr ffff88800bf88128 by task tcp_ao_vrf_race/232
Call Trace: tcp_inbound_ao_hash+0x585/0x19f0 tcp_inbound_hash+0x677/0xa80 tcp_v4_rcv+0x1c3e/0x3ab0
Allocated by task 235: tcp_ao_alloc_info+0x43/0xf0 tcp_ao_add_cmd+0xdf7/0x13b0 do_tcp_setsockopt+0x168c/0x2640
Freed by task 235: kfree+0x1b8/0x550 tcp_connect+0x252/0x4f00 tcp_v4_connect+0x1114/0x1720
不正なアドレスは、解放された128バイトのオブジェクト内のオフセット40バイトにあり、tcp_ao_info counters.key_not_foundフィールドと一致します。2回のテストではそれぞれ1000回試行し、no-keyパスに366回および411回到達し、それぞれ1件および2件のKASANレポートを生成しました。この変更により、同じ再現プログラムは1000回の試行でno-keyパスに366回到達しましたが、KASANレポートやoops（カーネルパニック）は発生しませんでした。
no-keyパスにはtcp_ao_destroy_sock()を使用します。これによりAO情報が非公開化され、ソケットメモリおよびstatic-keyの会計処理が更新され、解放がRCU grace periodの後まで延期されます。
また、WARN_ON_ONCE()とその古いコメントを削除しました。VRFデタッチによる競合は通常の運用中にno-key状態に到達可能であるため、これは不可能なアサーションではなく処理済みの条件です。panic_on_warnカーネルでは、このWARNが処理済みの競合をカーネルパニックに変えてしまいます。
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.