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

Linux kernel mlx5e に解放の誤り、修正版あり

Linux kernel の mlx5e ドライバーに、メモリ確保に失敗した後の再試行で同じバッファを二重に解放してしまう欠陥が見つかりました。影響が出るのは、mlx5 系のネットワークカードで AF_XDP のゼロコピー受信を使っている環境です。該当する場合は、修正版のカーネルまたはディストリビューションの更新パッケージを計画的に適用してください。

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

急ぎ度: 早めに

CVSSは9.8ですが、影響を受けるのはmlx5系NICでAF_XDPを使う限られた構成で、実際の攻撃での悪用は公表されていないためです。

関係があるか

mlx5eドライバーを使うNVIDIA（旧Mellanox）系のネットワークカードを載せた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 で稼働中のカーネルの版を確認し、上の表の範囲に入るか照らし合わせます。
  2. 2lsmod | grep mlx5_core でmlx5のドライバーが読み込まれているかを確認します。何も表示されなければ、このドライバーは使われていません。
  3. 3ethtool -i <インターフェース名> で、通信に使っているNICのドライバーがmlx5_coreかどうかを確認します。
  4. 4AF_XDP(XSK)のゼロコピー受信を使うアプリケーションが動いているかを、アプリケーションの担当者に確認します。高速パケット処理や監視用の基盤などが典型的な利用例です。

何が起きたか

Linux kernelのネットワークカード用ドライバーmlx5eで、メモリの後始末を誤る欠陥が見つかりました。一時的にメモリが足りなくなって処理をやり直すとき、すでに返却済みで、別の用途にもう割り当てられているかもしれないバッファを、もう一度返却しようとすることがあります。同じ物を二度片付けるため、カーネル内部のメモリ管理が乱れるおそれがあります。

仕組みはこうです。AF_XDPをstriding RQと組み合わせて使う場合、mlx5eはXSKバッファの解放を、MPWQE（受信用の領域）を補充する時点まで遅らせます。補充の途中でXSKバッファの確保が -ENOMEMで失敗すると、処理位置（actual_wq_head）が進まず、次のNAPI pollで同じWQEがやり直されます。

ところが mlx5e_free_rx_mpwqe() は、解放済みのスロットを「まだ解放できる」状態のまま残していました。やり直しのときに、古いポインタを通して xsk_buff_free() がもう一度呼ばれ、すでにXSKプールへ戻って再配分されたバッファを解放してしまいます。

修正では、mlx5e_xsk_alloc_rx_mpwqe() の共通のエラー経路で skip_release_bitmap のすべてのビットを立てます。これで再試行時に二重解放が起きません。成功時の経路は変わりません。開発側の試験では、失敗を意図的に3回連続で起こしても元の16個のXSKバッファが一度だけ解放されることが確認されています。20秒間の負荷試験では、約157万回のバッファ確保失敗を発生させても、不正なディスクリプタやWQEエラー、カーネルの警告は出ませんでした。

攻撃の流れ

  1. 1

    ゼロコピー受信

    mlx5系NICでAF_XDPのゼロコピー受信が使われています。

  2. 2

    確保の失敗

    メモリ不足などでXSKバッファの確保が -ENOMEMで失敗します。

  3. 3

    同じWQEを再試行

    処理位置が進まないため、次のNAPI pollで同じ領域の補充がやり直されます。

  4. 4

    二重解放

    解放済みの印が残っていて、再配分済みのバッファを古いポインタで再び解放します。

  5. 5

    メモリ管理の乱れ

    バッファの管理情報が壊れ、停止や情報漏えいなどにつながるおそれがあります。

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

どう悪用されるか

CVSSの評価は、ネットワーク経由で、認証も利用者の操作も不要という前提です（AV:N/AC:L/PR:N/UI:N）。ただし、この欠陥が働くには、該当ドライバーとAF_XDPのゼロコピー受信が使われていて、かつバッファの確保失敗が起きる状況が必要です。実際に影響を受ける環境は、点数から受ける印象よりずっと絞られます。

被害としてCVSSは、機密性・完全性・可用性のすべてに高い影響を想定しています。二重解放はカーネルのメモリ管理を乱すため、通信の異常やシステムの停止につながるおそれがあります。ただし、具体的な悪用手法や実際の被害は公表されていません。実際の攻撃で悪用されたという情報も、現時点では公表されていません。

今すぐやること

  1. 1

    該当するか確認する

    カーネルの版、mlx5_coreの使用、AF_XDPの利用有無の3点を確認します。mlx5_coreを使っていない、またはAF_XDPを使っていないサーバーは、通常の更新サイクルで対応すれば足ります。

    uname -r
  2. 2

    ドライバーの使用を確かめる

    通信に使っているNICがmlx5_coreかどうかを確認します。インターフェース名は環境に合わせて置き換えてください。

    ethtool -i eth0
  3. 3

    修正版へ更新する

    ディストリビューションが提供する更新カーネルを適用し、再起動して反映させます。自前でカーネルを管理している場合は、6.6.160、6.12.113、6.18.57、7.2.11以降のうち、使っている系列の版へ上げます。

  4. 4

    優先順位をつける

    AF_XDPを使う高速パケット処理基盤や、外部からのトラフィックを直接受ける機器を先に更新します。それ以外は通常の保守枠で構いません。

  5. 5

    ベンダーの告知を確認する

    配布版カーネルや、ネットワーク機器・アプライアンスに組み込まれたLinuxについては、提供元の告知で修正済みの版を確認します。

すぐ更新できないとき

公式な回避策は公表されていません。更新まで時間がかかる場合は、影響を受けるNIC上でAF_XDPのゼロコピー受信を使うアプリケーションを止めるか、使わない構成にすることで、この欠陥が働く経路を避けられる可能性があります。ただし、業務への影響が大きいため、アプリケーションの担当者と相談したうえで判断してください。

背景

mlx5eは、NVIDIA（旧Mellanox）のConnectX系ネットワークカードを動かすLinuxのドライバーです。データセンターやクラウド基盤、高速な通信が求められるサーバーでよく使われます。AF_XDPは、通信の受け渡しをカーネルの通常の経路より短くして、アプリケーションが高速にパケットを処理できるようにする仕組みです。ゼロコピーでは、カーネルとアプリケーションが同じメモリ領域を共有します。そのため、バッファの貸し借りの管理を誤ると、影響が大きくなりやすい特徴があります。

メモリを二重に解放する欠陥は、OSのカーネルやドライバーで繰り返し問題になってきた種類の弱点です。処理が成功する通常の経路ではなく、メモリ不足のような異常時の再試行で起きることが多く、通常の動作確認では見つかりにくいのが特徴です。今回も、失敗を意図的に起こす試験で確認された経路が修正対象になっています。

よくある質問

Q.CVSSが9.8なので、全てのLinuxサーバーで緊急対応が必要ですか。
A.必要とは言えません。影響を受けるのはmlx5eドライバーを使い、AF_XDPのゼロコピー受信を使う環境です。まず自社の構成が該当するかを確認し、該当するものから更新してください。
Q.すでに攻撃に使われていますか。
A.実際の攻撃で悪用されたという情報は、現時点で公表されていません。状況が変わることもあるため、ディストリビューションやNVDの更新を確認してください。
Q.版番号が修正版より古くても安全な場合はありますか。
A.あります。配布版のカーネルは、版番号を上げずに修正だけを取り込むことがあります。ディストリビューションのセキュリティ情報で、このCVEへの対応状況を確認してください。

まだ分かっていないこと

  • この欠陥を使った具体的な攻撃手法や、実際の被害の有無は公表されていません。
  • ネットワーク経由で外部から条件を満たせるかなど、CVSSの想定が現実の環境でどこまで当てはまるかは明らかになっていません。
  • 各ディストリビューションが、どの版で修正を取り込んだかは、それぞれの告知を確認する必要があります。

この記事は、取得元の公開情報をもとに生成 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 MPWQE refill retry

With AF_XDP on a striding RQ, mlx5e defers releasing XSK buffers until
an MPWQE is refilled. If XSK allocation then returns -ENOMEM,
actual_wq_head is not advanced and a later NAPI poll retries the same
WQE.

mlx5e_free_rx_mpwqe() leaves each released slot marked as releasable. On
retry it can therefore call xsk_buff_free() again through stale pointers
after the frames have returned to the XSK pool and been reallocated.

Set all skip_release_bitmap bits in the common error path of
mlx5e_xsk_alloc_rx_mpwqe(). This matches mlx5e_alloc_rx_mpwqe(). A
successful allocation already clears the bitmap after replacing every
buffer, so retries become idempotent without changing the success path.

Fault injection forced three consecutive failures for one selected MPWQE.
Both an early allocation failure and a partial 8-of-16-buffer unwind
released the original 16 XSK buffers only once. Each error left a full
bitmap, the following NAPI retry skipped the release, and a later
successful allocation cleared it. A 20-second AF_XDP zero-copy pressure
run exercised 1,575,262 buffer allocation failures without invalid
descriptors, WQE errors, or kernel warnings.

出典: Linux kernel CVE announcements NVD GitHub Advisory

参照URL

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