本文へ移動
English version →
ログイン 新規登録
JA EN FR
SecPulse
重大 9.8 急ぎ度: 早めに

Linux kernel mlx5eにXSKバッファ二重解放の欠陥、修正版あり

Linux kernelのNVIDIA(Mellanox)系NICドライバ mlx5e に、AF_XDPのゼロコピー受信でメモリ上の受信バッファが誤って二重に扱われる欠陥が見つかりました。該当するのは mlx5 系NICでAF_XDPを使う環境で、修正版は6.6.160、6.12.113、6.18.57、7.2.11です。実際の攻撃での悪用は現時点で明らかになっていないため、対象環境かどうかを確認したうえで、カーネルの更新を計画してください。

CVE-2026-99079 公開 生成 AI で作成
記事のイメージ(生成 AI による画像)
画像は生成 AI で作成したイメージです

急ぎ度: 早めに

CVSSは9.8と高い一方、影響が出るのはmlx5系NICでAF_XDPのゼロコピーを使う環境に限られ、悪用の確認も公表されていないため、該当環境では早めの更新が適切です。

関係があるか

mlx5系NIC（mlx5_coreドライバ）を使い、AF_XDPソケットでゼロコピー受信を行っているLinuxサーバーが対象です。高速なパケット処理やネットワーク機器向けの用途で使う環境が主に該当し、AF_XDPを使っていない一般的なサーバーでは、この欠陥の経路を通りません。

製品影響を受ける版直った版
Linux kernel 6.6系 6.4.0以上6.6.160未満 6.6.160
Linux kernel 6.12系 6.7.0以上6.12.113未満 6.12.113
Linux kernel 6.18系 6.13.0以上6.18.57未満 6.18.57
Linux kernel 7.2系 6.19.0以上7.2.11未満 7.2.11

確かめ方

  1. 1uname -r で稼働中のカーネル版を確認し、上の影響範囲に入るか照らし合わせます。ディストリビューションは修正を古い版番号のまま取り込むことがあるため、版番号だけで判断せず、各ディストリビューションのセキュリティ告知でCVE-2026-99079の扱いを確認してください。
  2. 2lsmod | grep mlx5 でmlx5系ドライバが読み込まれているかを確認します。ethtool -i <インターフェース名> のdriver欄がmlx5_coreであれば、そのNICが対象のドライバを使っています。
  3. 3AF_XDPソケットを使うアプリケーション（高速パケット処理ソフトなど）を、そのNIC上で動かしているかを、アプリケーションの担当者や設定で確認します。使っていなければ、この欠陥の経路には入りません。

何が起きたか

Linux kernelのNVIDIA(Mellanox)製NIC向けドライバmlx5eに、受信用メモリ領域の管理の誤りがありました。パケットを高速に処理するAF_XDPという仕組みで、受け取り側の処理が追いつかず受信キューが満杯になると、同じメモリ領域をカーネルとドライバが別々に解放してしまう場合があります。結果として、すでに別の用途に割り当て直された領域が解放されたり、同じ領域が二重に受け渡されたりします。

技術的には、AF_XDPソケットへのXDPリダイレクトが、受信リング満杯で失敗した場合が発端です。このときXSKコア側がバッファを解放します。その後、legacy cyclic RQの一括補充処理で、mlx5eも補充の前にWQEのXSKバッファを解放します。補充が一部しか成功しないと、代わりのバッファを得られなかったWQEには古いバッファのポインタが残ります。そのバッファが別のWQEに割り当てられた後、補充の再試行で古いポインタ経由で使用中のバッファが解放され、同じUMEMフレームが二重に公開されます。

修正では、ドライバ側で解放した直後にWQEを「解放済み」と印を付けるようにしました。この印は代わりのバッファが割り当てられると解除される仕組みがすでにあるため、再試行時に古いポインタを解放することがなくなります。報告によると、この不具合は警告やエラーログを出さずに起きます。検証用の再現プログラムで、64バイトのUDPパケットを毎秒1,200万個流したところ、修正前は約4秒、約285万パケットで処理が止まり、所有権やデータの二重公開に関するエラーが64件検出されました。修正後は30秒間で約3億5,690万パケットを処理し、エラーは出ませんでした。

攻撃の流れ

  1. 1

    受信キュー満杯

    AF_XDPソケットの受信リングが一杯になり、リダイレクトが失敗してXSKコアがバッファを解放します。

  2. 2

    ドライバも解放

    続く一括補充で、mlx5eも同じWQEのバッファを補充前に解放します。

  3. 3

    古い参照が残る

    補充が一部しか成功せず、代わりのバッファがないWQEに古いポインタが残ります。

  4. 4

    領域の再利用

    解放された領域が別のWQEに割り当てられ、使用中の状態になります。

  5. 5

    誤った解放

    補充の再試行が古いポインタ経由で使用中の領域を解放し、同じフレームが二重に公開されます。

公開されている情報をもとにした流れの例です。

どう悪用されるか

CVSS 3.1の評価は、ネットワーク経由、認証不要、利用者の操作不要となっており、基本スコアは9.8(critical)です。ただし、問題が起きる条件はmlx5系NICでAF_XDPのゼロコピー受信を使い、受信リングが満杯になる状況です。検証では大量の小さなパケットを流して再現しており、通常の負荷では起きにくい可能性もありますが、実環境でどの程度起きるかは公表されていません。

起こりうる影響は、公表されている範囲では、パケット処理の停止と、バッファの所有権やデータの不整合です。検証では修正前のカーネルで処理が途中で止まり、所有権とデータに関するエラーが出ました。任意のコードが実行できるかどうかについては、公表されていません。実際の攻撃での悪用についても、現時点で明らかになっていません。

今すぐやること

  1. 1

    対象環境かどうかを確認する

    mlx5系NICを使っているサーバーを洗い出し、そのNICでAF_XDPを使うアプリケーションが動いているかを確認します。該当しないサーバーは、通常のカーネル更新の計画に組み込めば足ります。

    uname -r
  2. 2

    ドライバとNICを確認する

    NICがmlx5_coreドライバで動いているかを確認します。インターフェース名は環境に合わせて置き換えてください。

    ethtool -i eth0
  3. 3

    修正版のカーネルへ更新する

    使用中の系統に応じて、6.6.160、6.12.113、6.18.57、7.2.11以降のカーネル、またはディストリビューションが提供する修正入りのカーネルに更新します。更新後は再起動して、新しいカーネルで動いていることを確認します。

  4. 4

    ディストリビューションの告知を確認する

    パッケージの版番号が上の修正版より小さく見えても、修正が取り込まれている場合があります。ベンダーのセキュリティ情報でCVE-2026-99079の対応状況を確認してください。

  5. 5

    更新後に高負荷時の動作を検証する

    AF_XDPを使う本番相当の環境では、更新後に高負荷時のパケット処理が正常に続くかを、検証環境で先に確かめてから展開します。

すぐ更新できないとき

公式な回避策は公表されていません。更新が難しい場合は、対象のNICでAF_XDPのゼロコピー受信を使わない構成にすることが考えられますが、性能や動作への影響があるため、事前に検証してください。判断に迷う場合は、ディストリビューションやNICベンダーの案内を確認してください。

背景

mlx5eは、NVIDIA（旧Mellanox）製のConnectXシリーズなどのNICをLinuxで動かすためのドライバです。データセンターやクラウド基盤、高速な通信を扱うサーバーで広く使われています。AF_XDPは、カーネルの通常のネットワーク処理を一部飛ばして、ユーザー空間のアプリケーションへパケットを高速に渡す仕組みで、ゼロコピーモードではNICの受信用メモリをアプリケーションと共有します。

このように、メモリを複数の部品で共有して受け渡す設計では、誰がいつ解放するかの管理が複雑になります。解放済みの領域を参照し続けたり、同じ領域を二重に解放したりする不具合は、OSのドライバやネットワーク処理で繰り返し見つかってきた種類の弱点です。多くは、高負荷や処理失敗といった普段通らない経路で表に出ます。

よくある質問

Q.mlx5系NICを使っていますが、AF_XDPは使っていません。対応は必要ですか。
A.説明されている不具合は、AF_XDPのゼロコピー受信で起きる経路です。AF_XDPを使っていなければ、この経路には入らないと考えられます。ただし、カーネルの更新は通常の保守として行っておくのが望ましいです。
Q.CVSSが9.8なのに、急ぎ度が「至急」ではないのはなぜですか。
A.実際の攻撃での悪用が確認されたとは公表されておらず、影響を受ける環境もmlx5系NICとAF_XDPの組み合わせに限られるためです。該当する環境では、早めに更新してください。
Q.遠隔からサーバーを乗っ取られる欠陥ですか。
A.CVSSの評価はネットワーク経由で認証不要となっていますが、公表された情報で確認できる影響は、パケット処理の停止とバッファやデータの不整合です。コード実行については公表されていません。
Q.被害が出ていても気づけますか。
A.報告では、この不具合はカーネルの警告やエラーログを出さずに起きるとされています。ログに何も出ないことを安全の根拠にはせず、版の確認と更新で対処してください。

まだ分かっていないこと

  • 実際の攻撃での悪用が確認されているかは、現時点で明らかになっていません。
  • 任意コードの実行や権限昇格につながるかは公表されていません。
  • 各ディストリビューションの修正版の提供状況と版番号は、それぞれのベンダーの告知で確認する必要があります。

この記事は、取得元の公開情報をもとに生成 AI で作成しています。誤りを含むことがあります。対応を決める前に、下の原文と参照先を確認してください。

影響パッケージ

種類パッケージ影響を受ける版直った版
Linux Linux — —
Linux Kernel
6.4.0 以上 6.6.160 未満
6.7.0 以上 6.12.113 未満
6.13.0 以上 6.18.57 未満
6.19.0 以上 7.2.11 未満
6.6.160
6.12.113
6.18.57
7.2.11

ディストリビューション別の修正状況

各ディストリビューションが公開している、この CVE の修正パッケージ

原文の説明 取得元が公開している説明をそのまま載せています (多くは英語)。

In the Linux kernel, the following vulnerability has been resolved:

net/mlx5e: Prevent stale XSK buffer release on refill retry

When an XDP redirect to an AF_XDP socket fails because its RX ring is
full, the XSK core frees the buffer. During the subsequent batched refill
of a legacy cyclic RQ, mlx5e also releases the WQE's XSK buffer before
allocating a replacement. If that refill succeeds only partially, a WQE
left without a replacement retains its old buffer pointer.

The buffer can meanwhile be allocated to another WQE. A later refill
retry can then free the live buffer through the stale pointer and publish
the same UMEM frame twice.

Mark the WQE as released immediately after the driver-side free. The flag
is already cleared when a replacement buffer is assigned, so refill
retries no longer release stale pointers.

The failure is silent and produces no kernel warning or splat. A
standalone legacy cyclic-RQ zero-copy libxsk reproducer, using 64-byte UDP
traffic offered at 12 Mpps, detected it: stock stopped after 2,854,914
packets in 4.094 seconds, with 4,542 xdp_rx_ring_full events and 64
ownership/double-publication errors. With this change it processed
356,904,225 packets in 30 seconds despite 571,405 xdp_rx_ring_full events,
with no ownership or data errors.

出典: Linux kernel CVE announcements NVD GitHub Advisory

参照URL

当サイトでは、アクセス解析と広告の効果測定のために Cookie を使います。株式会社Game のサイト共通の設定です。 詳しく