LinuxカーネルのUDP処理に解放済みメモリ使用、一般ユーザーからrootへの道も。実サーバーでの悪用はクラッシュのみ確認

まず初めに

20年以上、カーネルの一番奥の棚に置かれたままだった地雷である。踏むには「同じマシンに一般ユーザーで入っていること」が要るので、玄関から殴り込める類の話ではない。だが共用サーバーという長屋では、隣の部屋の住人が天井を踏み抜けば、棟ごと落ちる。地味な前提条件の裏に、長屋暮らし全員分のリスクがぶら下がっている。

※個人の感想です

欠陥の仕組み——bindとタイムスタンプ取得の競合

AlmaLinuxの解説によると、カーネル内の各ソケットはフラグの集まり（ビット列）を持ち、このビット列の変更は「ソケットのロックを取った状態でだけ行う」というのがカーネルの決まりです。ロックなしに2つの処理が同じビット列を読み書きすると、後から書いた側が、先に立てたフラグを静かに消してしまうためです。

規則を破っていたのが、パケットの到着時刻を尋ねる SIOCGSTAMP 系のioctlです。初回呼び出しでタイムスタンプ機能を有効化する際、ロックを取らずにフラグを書き換えていました。ここへ、UDPソケットをポートへ結びつける bind() が競合すると、bind側が立てた「このソケットは猶予期間が過ぎるまで解放するな」という意味のフラグ（SOCK_RCU_FREE）が消えてしまいます。UDPの受信経路はロックを取らずにソケットを参照する設計のため、閉じられたソケットが即座に解放されると、受信経路が解放済みのメモリを指したままになる、というのがuse-after-freeの構図です。

上流の修正はEric Dumazet氏が書き、ioctl側で「フラグを実際に立てる必要がある場合だけソケットのロックを取る」形にしました。通常経路はロックなしのままにしてあるため、性能への影響を抑えた修正です。報告者はJungwoo Lee氏とWongi Lee氏で、メモリ検査機能（KASAN）によるuse-after-freeの実証が報告されています。

評価は割れている——7.8か、7.0か

深刻度の評価は、出す側によって分かれています。LinuxカーネルのCVEチームはCVSS 7.8（High）とし、AlmaLinuxもこの数字を引いています。一方、Red Hatは「競合に安定して勝つのは難しい」としてCVSS 7.0、深刻度はModerate（中程度）と評価しました。

数字の違いは、欠陥の性質そのものではなく「競合をどれだけ確実に再現できるか」の見立ての違いです。どちらの評価でも、前提が「ローカルの一般ユーザーとしてコードを実行できること」である点は共通しています。単体のパソコンで自分しか使わない環境と、不特定多数のコードが同居するサーバー環境では、同じ7点台でも意味が変わります。

実際に突かれたサーバーと、rootの再現は別の話

CloudLinuxは11月7日更新の記事で、実環境での悪用を報告しています。2026年11月4日、同社のCloudLinux 8サーバーがこの欠陥に対する攻撃を受け、12回クラッシュしました。そのサーバーはカーネルエラー時に再起動する設定（kernel.panic_on_oops = 1）だったため、クラッシュのたびにサーバー全体が再起動しています。同社がそのサーバーで確認したのはクラッシュまでで、root権限の取得までは確認されていません。

root取得については、同社の技術者が社内で別途再現した、という位置づけです。「実サーバーでrootを取られた」と「実験環境でrootまで行けた」は、重さが違います。本記事ではこの2つを分けて書いています。なお、CloudLinuxは公開された攻撃コードは無いとしており、AlmaLinuxも「公開されたエクスプロイトは把握していない」としています。

対応状況——ディストリビューションごとに足並みが違う

対応はディストリビューションごとに進み方が異なります。

• AlmaLinux: 8、9、10が影響を受けます。修正カーネルはテストリポジトリで公開済みで、版数は8が kernel-4.18.0-553.184.2.el8_10、9が kernel-5.14.0-687.66.2.el9_8、10が kernel-6.12.0-211.74.2.el10_2 です。検証後に本番リポジトリへ移す予定としています。執筆時点で、Red HatのRHEL向け修正カーネルはまだ無く、RHEL 8、9、10は影響ありとされています。AlmaLinux 8（4.18系）は2019年のioctlまわりの作り替えより前のカーネルのため、上流の修正をそのまま当てられず、相当する仕組みへ合わせ込む作業が必要だったことも明かされています。
• CloudLinux: 対象は7、7h、8、8 LTS、9、9 LTS、10で、Ubuntu 22.04向けは確認中としています。7hと8向けの修正カーネル（4.18.0-553.184.1.lve.1）は段階的配信中、8 LTSと9 LTS向けは安定チャネルで11月2日から提供中です。再起動なしで当てるKernelCareのライブパッチは、CloudLinux 8向けが11月6日08:50 UTCから本番フィードに載り、9と10向けは準備中とされています。適用確認は kcarectl --patch-info でCVE番号を検索する方法が案内されています。

回避策について、両社とも「実用的な回避策は無い」としています。トリガーは通常のUDPソケットへの通常のioctlであり、止めるモジュールもファイアウォールの規則もありません。プログラムを実行できる利用者を絞ることは露出を下げるだけで、穴そのものは塞がりません。

誰が急ぐべきか

優先度が高いのは、複数の利用者や顧客のコードが同じカーネル上で動く環境です。共有ホスティングでは、1つのホスティングアカウント、あるいは侵害された1つのサイトが「一般ユーザーとしてコードを実行できる」状態に当たります。そこから先は、そのサーバーに同居する全サイト、全メールボックス、全データベースの問題になります。CIランナーや、利用者が持ち込んだコンテナを動かす基盤も同じ構造です。

逆に、利用者が自分だけの個人用マシンでは、緊急度は下がります。ただし「下がる」であって「無い」ではありません。通常の更新の流れでカーネルを上げておく対象ではあります。

IT Postの見方

IT Postでは、この件の教訓は「ローカル前提の脆弱性は、クラウドと共用基盤の時代には前提が一番安い部分になった」という点だと考えます。昔なら「まず侵入されることが先」という二段構えの話でした。今は、サイト1つの侵害や、CIに外からコードが入ること自体が日常の出来事で、そこから先の段差がこの欠陥で消える。評価が7.8と7.0に割れていること自体、競合の再現性という不確かな部分に依存している証拠で、IT Postでは「当たりにくいから後回し」ではなく「当たった側の実例（12回のクラッシュ）が既にある」ことを重く見ます。

もう1つ、地味だが見逃せないのは修正の足並みです。上流で直っても、RHELの修正待ち、AlmaLinuxは自前で先行移植、CloudLinuxはライブパッチと段階配信と、同じ欠陥でも「自分のサーバーの番がいつ来るか」が製品ごとに違う。IT Postでは、CVE番号で一括りにせず、使っているディストリビューションの案内で自社の状態を確認するのが、この手の件での正しい実務だと考えます。

今後どうなりそうか

今後の確認点は、RHEL向け修正カーネルの提供時期、AlmaLinuxの修正版がテストから本番リポジトリへ移る時期、CloudLinuxの残りの系統向けライブパッチの提供、そして悪用範囲の拡大の有無です。公開された攻撃コードが無い現状でも、CloudLinuxの実例が示すとおり、悪用自体は始まっています。

IT Postでは、新しい公式情報が確認できれば、本記事を更新します。