Linuxカーネルのパケットスケジューリングを担うnet/schedサブシステムに、ローカルユーザーによるroot権限の取得につながる解放後利用(UAF)の脆弱性CVE-2026-53264が確認されました。上流および複数の安定版カーネルでは修正済みですが、修正を取り込んでいないディストリビューションのカーネルは引き続き影響を受ける可能性があります。
シンガポールのセキュリティ企業STAR Labsの研究者Lee Jia Jie氏は2026年7月27日、同氏が独自に発見したこの脆弱性について技術writeupを公開しました。CentOS Stream 9を対象に調整したローカル権限昇格の実証コード(PoC)も公開しています。Linux Kernel CNAによるCVSS v3.1の基本値は7.8(High)です。
今回の研究で注目されるのは、Lee氏が脆弱性の発見、KASAN(Kernel Address Sanitizer)を利用した初期PoCの作成、レースコンディションの成立確率を高める調整など、複数の工程でAIを利用したと説明している点です。一方で、AIには推論上の見落としや限界があり、最終的な判断や細部の調整には、人間による対象サブシステムへの理解が不可欠だったとも述べています。
CVE-2026-53264の全体像
| 項目 | 内容 |
|---|---|
| CVE番号 | CVE-2026-53264 |
| 影響コンポーネント | Linuxカーネルのnet/sched(トラフィック制御)サブシステム |
| 脆弱性種別 | 競合状態に起因する解放後利用(UAF) |
| 影響 | ローカル権限昇格(LPE) |
| CVSSスコア | 7.8(High、Linux Kernel CNA) |
| 影響開始点 | Linux Kernel CNAはLinux 4.14を影響開始点として記載 |
| 上流の修正済みバージョン | 5.10.259、5.15.210、6.1.176、6.6.143、6.12.94、6.18.36、7.0.13。メインラインでは7.1-rc7に修正を収録 |
| 公開PoCの主な成立条件 | 非特権ユーザー名前空間の有効化、必要なトラフィック制御機能、対象カーネルに合わせた調整 |
| 公開状況 | CentOS Stream 9を対象に調整した実証コードが公開済み |
| 推奨対処 | 使用中のディストリビューションが提供する修正済みカーネルへの更新と再起動 |
脆弱性の原因 — オブジェクトの解放を適切に遅延できていなかった
net/schedは、Linuxにおけるパケットスケジューリングやトラフィック制御を担うサブシステムです。デバイスドライバの上位に位置し、パケットを送信する時点、順序、および送信可否を制御します。また、netlinkを通じてパケット処理ルールを設定するための仕組みも提供しています。
net/schedでは、チェーン、フィルタ、アクションなどの複数の要素を組み合わせてパケットの処理内容を決定します。このうちアクションは、同じネットワーク名前空間内で共有でき、一意のインデックスを使って管理されます。
CVE-2026-53264では、フィルタの作成処理と削除処理が同時に実行された場合に、アクションオブジェクトの参照と解放が競合する可能性がありました。ある処理がオブジェクトを参照している間に、別の処理が同じオブジェクトを削除して即座にメモリを解放すると、参照側がすでに解放された領域へアクセスするUAFが発生します。
Linuxカーネルで使用されているRCU(Read-Copy-Update)は、ほかの処理がオブジェクトを参照している可能性がある間、実際のメモリ解放を遅延させる仕組みです。しかし、脆弱な処理では、既存のRCUリーダーが処理を終えるまで待たずにオブジェクトが解放されていました。
上流の修正では、RCUの猶予期間が経過するまで最終的なメモリ解放を延期するよう処理が変更されています。これにより、参照中のオブジェクトが途中で解放される競合状態を防ぎます。
影響バージョン — Linux 4.14以降のすべてが脆弱という意味ではない
Linux Kernel CNAは、CVE-2026-53264の影響開始点をLinux 4.14としています。ただし、これはLinux 4.14以降のすべてのカーネルが現在も脆弱であることを意味しません。
各安定版カーネル系列では、次のバージョンから修正が反映されています。
- 5.10系列: 5.10.259以降
- 5.15系列: 5.15.210以降
- 6.1系列: 6.1.176以降
- 6.6系列: 6.6.143以降
- 6.12系列: 6.12.94以降
- 6.18系列: 6.18.36以降
- 7.0系列: 7.0.13以降
- メインライン: 7.1-rc7以降
Ubuntu、Debian、Red Hat、SUSEなどのLinuxディストリビューションでは、上流の修正を独自のカーネルパッケージへバックポートする場合があります。そのため、上流カーネルのバージョン番号だけを見て、影響の有無を判断することはできません。
使用しているディストリビューション、リリース、カーネルフレーバーごとに、各ベンダーの公式CVEトラッカーやセキュリティアドバイザリを確認する必要があります。
公開PoCの成立には複数の条件が必要
CVE-2026-53264は、インターネット経由で直接悪用されるリモートコード実行の脆弱性ではありません。攻撃者は、一般ユーザーのアカウントを取得している、別の脆弱性を通じて侵入しているなど、対象システム上でコードを実行できる状態にある必要があります。
さらに、Lee氏が公開した実証コードを通常の非特権ユーザーから成立させるには、複数の追加条件があります。
- 非特権ユーザー名前空間が有効であること:公開PoCでは、ユーザー自身が作成した名前空間内で、必要なネットワーク管理権限を取得します。
- 必要なカーネル機能が有効であること:公開PoCは、Linuxのトラフィック制御に関係する特定の機能を利用します。
- 対象カーネル向けに調整されていること:実証コードにはカーネルビルドごとに異なる内部情報が関係するため、別の環境でそのまま動作するとは限りません。
これらは、Lee氏が公開した実証コードに関する条件です。脆弱性そのものが、あらゆる状況で同じ条件を必要とすることを意味するわけではありません。
また、より新しいカーネルでは、公開PoCで使用されたものと同じ手法を適用することが難しい場合があるとLee氏は説明しています。ただし、修正を適用していない環境における脆弱性そのもののリスクがなくなるわけではありません。
公開PoCが示したリスク
Lee氏は、複数の処理を同時に実行することで、アクションオブジェクトの参照と削除が競合する状態を作り出しました。その後、解放されたメモリ領域が別のオブジェクトに再利用される状況を利用し、最終的にローカルユーザーからroot権限を取得できることを実証しています。
研究の初期段階では、レースコンディションが成立するまで15分を超える場合がありました。しかし、処理の待ち時間を調整する方法や、複数の処理を並列化する方法を取り入れることで、成立までの時間を約5秒へ短縮したと報告しています。
公開された実証コードはCentOS Stream 9を対象として調整されており、異なるディストリビューションやカーネルビルドで、そのまま同じ結果が得られることを示すものではありません。ただし、脆弱性が理論上の問題にとどまらず、条件を満たす環境では権限昇格につながることが実証された点は重要です。
本記事では、防御側が脆弱性の影響を把握するための概要にとどめ、実証コードの具体的な処理、再現手順、実行方法については扱いません。
AIを脆弱性の発見と検証に活用
Lee氏は、AIを脆弱性の発見、KASANを使用した初期PoCの作成、レースコンディションの改善に利用したと説明しています。
以前に取り組んだ修正済み脆弱性のn-day分析と比べ、今回はすべての内部処理を一から理解することよりも、実証コードを短期間で完成させ、改善することに重点を置いていました。AIは反復作業を高速化し、脆弱性探索のプロセスをより高い視点から考える上で有効だったとしています。
Lee氏は、新しい脆弱性を扱っているにもかかわらず、既知の脆弱性を分析するn-day研究に近い感覚だったと振り返っています。
一方で、AIには推論上の見落としや明確な死角があり、細部の調整では研究者自身の判断が不可欠でした。対象サブシステムを深く理解することで、AIが見落とした着眼点を発見できる可能性が高まるとして、人間の専門知識には引き続き大きな価値があると強調しています。
先行報告者とTyphoonPwn 2026での経緯
Linuxカーネルの上流修正では、KyleBotのハンドルで知られるKyle Zeng氏が報告者としてクレジットされています。Lee氏は同じ脆弱性を独自に発見していましたが、後になってZeng氏がTyphoonPwn 2026の2日前に同じ問題を先行報告していたことを知ったと説明しています。
Lee氏はTyphoonPwn 2026に向け、CentOS Stream 9デスクトップを対象に実証コードを調整していました。同競技会のLinux LPEカテゴリでは、参加者に無作為の実演順が割り当てられ、最初にroot権限の取得に成功した3名が勝者となる方式が採用されていました。
競技会前日の2026年5月27日、Lee氏は11人中8番目の実演順を割り当てられました。同日の午後3時13分までに3名の勝者が決まり、カテゴリが締め切られたため、Lee氏の実証コードは競技会で実演されませんでした。
研究者の環境では10回すべて成功
Lee氏は、CentOS Stream 9をインストールしたIntel Core i5-1235U搭載ノートPCで、最終版の実証コードを連続10回実行しました。本人の報告では10回すべてに成功し、所要時間は9秒から111秒でした。
後半の実行で時間が長くなった原因について、Lee氏はCPU温度の上昇に伴うクロックスロットリングの可能性を挙げています。
ただし、この成功率と所要時間は研究者自身の環境における結果であり、第三者による独立した再現結果ではありません。また、別のカーネルやディストリビューションでも同じ成功率が得られることを示すものではありません。
ディストリビューションごとに異なる対応状況
2026年7月28日時点で、各Linuxディストリビューションの公式トラッカーに掲載されている対応状況は、製品やカーネルパッケージによって異なります。
Debian Security Trackerでは、bullseyeのセキュリティ更新向け5.10.259-1、bookworm向け6.1.176-1、trixie向け6.12.94-1などが修正済みとして掲載されています。セキュリティリポジトリでは、これらより新しい修正済みパッケージが提供されている場合もあります。
UbuntuはCVE-2026-53264の優先度をHigh、CVSSスコアを7.8と評価しています。公式トラッカーでは、複数の保守対象リリースおよびカーネルフレーバーがVulnerableとして掲載されています。
Ubuntuでは標準カーネルのほか、AWS、Azure、GCP、Oracle、Raspberry Pi、リアルタイムカーネルなど、多数のカーネルパッケージが個別に管理されています。利用中の環境と一致するパッケージの状態を確認してください。
各トラッカーの情報は更新される可能性があります。記事公開後に修正版が提供される場合もあるため、実際の対応時には最新の公式情報を確認する必要があります。
実務上の推奨対処
最も確実な対処は、利用しているディストリビューションが提供する修正済みカーネルパッケージを適用し、修正済みカーネルでシステムを再起動することです。
上流の修正済みバージョンと同じ番号でなくても、ディストリビューション側で修正が既存のカーネルへバックポートされている場合があります。バージョン番号だけで判断せず、ベンダーの公式CVE情報やセキュリティアドバイザリを基準にしてください。
公開PoCと同じ攻撃経路への露出を確認する場合は、次の点を調査します。
- 使用中のカーネルパッケージがベンダーの公式情報で修正済みか
- 非特権ユーザー名前空間が有効になっているか
- 公開PoCが使用するトラフィック制御機能がカーネルで有効になっているか
- 一般ユーザーや外部から侵入したプロセスがローカルコードを実行できる環境か
非特権ユーザー名前空間を業務上使用していない環境では、その無効化によって公開PoCと同じ攻撃経路を制限できる可能性があります。ただし、これはカーネル更新に代わる完全な修正ではありません。
ユーザー名前空間は、コンテナ、ブラウザのサンドボックス、アプリケーションの分離機能などで利用される場合があります。無効化する際は、稼働中のワークロードやセキュリティ機能への影響を事前に検証してください。
CVE-2026-53264は、リモートから直接悪用できる脆弱性ではなく、公開PoCにも複数の成立条件があります。一方で、条件を満たす環境では一般ユーザーからroot権限の取得につながることが実証されています。
複数の利用者を収容する共有サーバー、開発環境、デスクトップLinux、侵入後の権限昇格を重視すべき環境では、カーネル更新を優先して進めることが推奨されます。
一次情報・公式情報
When AI Makes 0-Days Feel Like N-Days(STAR Labs、Lee Jia Jie氏、2026年7月27日)
CVE-2026-53264実証コード(STAR Labs、GitHub)
net/sched: act_api: use RCU with deferred freeing for action lifecycle(kernel.org)
CVE-2026-53264(NVD)
ディストリビューション公式情報
CVE-2026-53264(Debian Security Tracker)
CVE-2026-53264(Ubuntu Security)
CVE-2026-53264(SUSE)
CVE-2026-53264(Red Hat Product Security)
コメント