rxgk_decrypt_skb() にある COW（copy-on-write）保護の欠如The Hacker News が伝えたところによると、Linux kernel の脆弱性 CVE-2026-31635 に対する PoC（Proof of Concept、攻撃の動作確認用コード）が公開されました。
この脆弱性の通称は DirtyDecrypt、別名 DirtyCBC です。
名前だけ見ると派手ですが、やっていることはかなり地味で、しかもかなり厄介です。
ローカルの一般ユーザーが、root 権限を奪える可能性がある。これが本質です。root は Linux における“最強の管理者権限”なので、ここを取られるとシステム全体がほぼ終わりです。個人的には、LPE は「ネット越しに来ないから大丈夫」と油断されやすいぶん、運用現場での被害が大きくなりやすいタイプだと思います。
この脆弱性は、rxgk_decrypt_skb() という処理にあります。
ここは、受信した sk_buff（socket buffer、ネットワークのデータを運ぶ入れ物のようなもの）を復号する場所です。
問題は、この処理の中で COW（copy-on-write） の保護が足りないこと。
COW は「共有中のメモリに書き込むとき、先にコピーを作ってから自分専用に書く」仕組みです。
これがあるおかげで、あるプロセスの書き込みが別プロセスに漏れません。
ところが DirtyDecrypt では、その守りが抜けているため、共有されているページキャッシュや、権限の高いプロセスのメモリに対して、望ましくない書き込みが起きる可能性があります。
結果として、/etc/shadow、/etc/sudoers、SUID binary など、重要ファイルにまで悪影響が及び、root 権限を奪う足がかりになりえます。
ここはかなり怖いです。
“単なるメモリの書き間違い”に見えて、実際には 権限昇格の踏み台 になってしまう。Linux カーネルのバグは、たまにこの「一見小さいのに致命傷」な性質があるから油断できません。
記事によると、DirtyDecrypt の影響を受けるのは CONFIG_RXGK が有効なディストリビューション です。例として挙がっているのは次の通りです。
つまり、すべての Linux ではない のがポイントです。
条件を満たす環境だけが対象なので、まずは自分の利用している distro や kernel 設定を確認する必要があります。
さらに、コンテナ環境でも注意が必要です。
もし脆弱な Linux kernel 上で worker node が動いているなら、pod からの脱出経路 になりうる、とされています。
これは地味に重要で、コンテナは「アプリの隔離」には強いけれど、kernel がやられたら土台ごと崩れる という現実を改めて思い出させます。
今回の DirtyDecrypt は、単独で突然ぽっと出てきた話ではありません。
記事では、これを Copy Fail（CVE-2026-31431） や Dirty Frag（CVE-2026-43284 / CVE-2026-43500）、Fragnesia（CVE-2026-46300） の“仲間”として扱っています。
共通点はどれも、最終的に root を取れてしまう LPE だということ。
つまり、Linux kernel のある領域で、似たような設計・実装ミスが繰り返し見つかっているわけです。
正直、これはかなり面白いというか、怖いというか。
攻撃者の視点では「使える型」が蓄積されていることになるし、防御側の視点では「またこの系統か」となります。
脆弱性は個別事件に見えて、実際には 同じクラスの欠陥が連鎖している ことが多いんですよね。
PoC が出た、というのは単に研究者が喜んでいる話ではありません。
攻撃コードが実際に動くことが示された という意味なので、防御側としては一段ギアを上げるべき段階です。
もちろん、PoC が公開されたから即座に世界中が感染する、という単純な話ではありません。
でも、悪用のハードルは確実に下がります。
特にローカル権限昇格は、すでに少しだけ侵入された環境で「最後のひと押し」として使われやすいので、実運用ではかなり嫌な存在です。
ここは技術に詳しくない人向けに、あえて超ざっくり言うと、root は Linux の「何でもできる人」です。
つまり root を取られると、そのマシンの信頼性がほぼ崩壊 します。
しかもサーバーなら、その1台が踏み台になって横展開されることもあるので、影響は“その箱だけ”にとどまりません。
記事の後半では、最近の脆弱性ラッシュを受けて、Linux kernel 開発者が killswitch の提案を検討していることにも触れています。
これは何かというと、ざっくり言えば
「危険な kernel 関数を、パッチが出るまで一時的に無効化する仕組み」
です。
Sasha Levin による提案では、権限を持つ管理者が特定の関数を実行せず固定値を返すようにして、緊急避難的に被害を抑える、という考え方です。
かなり荒っぽく見えますが、ゼロデイで今すぐ止めたい という状況では現実的な選択肢かもしれません。
個人的には、この発想はかなり興味深いです。
Linux は“安定性”が売りの世界なので、何でも止めればいいわけではありません。
でも、被害が広がる前に一時的な防波堤を作るという意味では、十分に理にかなっていると思います。
さらに記事では、Rocky Linux が security repository を用意した話も紹介されています。
これは、重大な脆弱性が公になったときに、通常のリリースサイクルを待たずに、緊急修正を配布しやすくするための仕組みです。
重要なのは、これが デフォルトでは無効 であること。
つまり、普段の安定性は守りつつ、必要な人だけ使える“逃げ道”として設計されています。
このバランス感覚はかなりいいと思います。
セキュリティ対応は速さが大事ですが、速さだけを優先すると今度は安定性が壊れる。
Linux 系のディストリビューションは、ここをどう両立するかで本当に苦労しているんですよね。
DirtyDecrypt は、Linux kernel の中でも CONFIG_RXGK が有効な環境に影響する local privilege escalation の脆弱性です。
COW 保護の欠如という、いかにもカーネルらしい深い場所のミスが、結果として root 奪取につながるのがポイントです。
PoC が公開されたことで、今後は実際の悪用リスクも高まるはずです。
該当する Linux 環境を使っているなら、自分のディストリビューションのアドバイザリや kernel 更新を必ず確認 したいところです。
こういう話を見るたびに思うのですが、Linux の強さは kernel の堅牢さに支えられている一方、その kernel に穴が空くと一気に話がひっくり返る。だからこそ、更新の速さと運用の慎重さ、両方が大事なんだと思います。
参考: DirtyDecrypt PoC Released for Linux Kernel CVE-2026-31635 LPE Vulnerability