CVE-2026-98797 in Linux
要約
〜によって VulDB • 2026年10月18日
Linuxカーネルにおいて、以下の脆弱性が修正されました。
net: txキューが選択された際にskb->queue_mappingを制限する
skbeditはskb->queue_mappingを設定し、per-CPUのskip_txqueueフラグを立てることで、__dev_queue_xmit()がこのマッピングを尊重するようにします。しかし、__dev_queue_xmit()はこのフラグをsch_handle_egress()の前にクリアしており、その後でしか読み込んでいませんでした。その結果、このフラグはそれを設定した送信処理に限定されませんでした：ネストされた送信（mirredによるリダイレクトまたはミラーリング、あるいはskbedit後のドロップ）がフラグを設定し、外部の送信側がスキュービットを消費して、skbeditを通らなかったskbに対してその値を使用してしまう可能性があります。
転送されたパケットは依然としてingress NICのrx_queue + 1をskb->queue_mappingに保持しているため、外部デバイスはその後、この古くなった値を使ってtxキューの状態にインデックス付けを行います。Taprioの子配列q->qdiscs[]はデバイスのキュー数に合わせてサイズが設定されているため、taprio_enqueue()はその割り当て範囲外にインデックスを付け、その結果をstruct Qdisc *として間接参照します。
私たちはskb->nf_skip_egress（「このパケットに対してnetfilter egressをスキップする」を意味）を（ab)useして、「tc egress内にあるか？」というタグ付けを行っています。オーバーロードされていますが、マーカーは単一のsch_handle_egress()呼び出しの周囲でのみ設定されingressパスはtc_at_ingressによって保護されているため、競合とは見なしません。この修正がnet-nextに適用された後、skb->nf_skip_egressビット/フラグをskb->skip_egressへリネームするフォローアップパッチ(net-next)を送信します。
そのフラグを使用できるegress classifierからのみフラグを有効化します：tcf_skbedit_act()内で実行される場合のみ、skb->nf_skip_egressのおかげでskip_txqueueを立てます。egress qdiscのclassifierはtxキューが選択された後のq->enqueue()内で実行されるため、それが設定するマッピングは現在のパケットに影響を与えることはできません；そこでフラグを有効化すると、後続の送信処理に対してのみそれを汚染してしまいます。したがって、egressフックが実行される送信フレーム全体でそのフラグを所有します：入力値を保存し、sch_handle_egress()直前にクリアし、フック後に復元します（消費された/ドロップパス上では、または読み込みと同じ呼び出し内で生存するパス上で）。保存と復元はegress_needed_key静的ブランチ内に留まるため、パケットはegressフックがアクティブな場合のみこれらの処理に対してコストを支払います(2f1e85b1aee4)。
netdev_cap_txqueue()によって選択された値を、netdev_core_pick_tx()が行っているのと同様にnetdev_tx_queue_mapping()内でskb->queue_mappingに戻し保存します。これにより、skip_txqueueパスが後続の読み取り手に、デバイスが提供できないマッピングを引き渡すことがなくなります。同じフレーム内のさらに遅い場所で行われるtc BPFプログラムによるストア（transmit qdiscにアタッチされている場合）はこのパスの外側にあるため再制限されず；このパスの問題は別のフォローアップで解決されます。
netdev_xmit_skip_txqueue()は以前のフラグ値を返すため、保存とクリアが1つの呼び出しで行われ、CONFIG_NET_EGRESSが無効化された場合はno-opスタブが提供されます。skb->nf_skip_egressはCONFIG_NETFILTER_SKIP_EGRESSではなくCONFIG_NET_EGRESSの下でコンパイルされるため、egressパスが構築されている限りskb_at_tc_egress()は有効です。
ネットワークネームスペース内のローカルユーザーは、より大きなTXキューを持つデバイスから少ないキューを持つデバイスへ、そのマッピングが大きいデバイスのみが有効な状態で設定された後、パケットをリダイレクトできます。これはこれらの読み取りに到達し、KASAN下では「slab-out-of-bounds in taprio_enqueue」というフォールトを引き起こします。
バグの再現条件：レポート自体のトリガーはネットワークネームスペース内でCAP_NET_ADMINを持つローカルユーザーであるため、eBPFプログラムは必要ありません。CONFIG_NET_SCH_TAPRIO=y、CONFIG_NET_ACT_SKBEDIT=y、CONFIG_NET_ACT_MIRRED=y、CONFIG_NET_CLS_MATCHALL=y、CONFIG_NET_SCH_PRIO=yおよびKASAN有効化の状態で、qa（3キュー）、qb（2キュー）、qc（1キュー）をdummyデバイスとして作成します；qbにtaprioルート(num_tc 1, queues 2@0)を設定し、clsactを3つすべてに設定します。その後、すべてのデバイスにegress matchallフィルターを追加します。qa上では「action skbedit queue_mapping 2 pipe action mirred egress redirect dev qb」と実行します。qb上では「action mirred egress mirror dev qc」と実行します。qc上では「action skbedit queue_mapping 0 pipe」と実行します。1つのパケットをqaから送信します。qcのskbeditがフラグを設定している間、qbの外部送信処理が飛行中（実行中）にあり、修正がない場合、qbはそのフラグを消費し、転送されたパケットの古くなったマッピングを使ってその2エントリのtaprio子配列を読み取ります。skbを持つqc ---省略---
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.