Dirty Frag（CVE-2026-43284 / 43500）とは何か——Copy Failの暫定策が効かない理由と未パッチ期の管理者アクション

ＨＯＭＥ ＞ リナックスマスター.JP 公式ブログ ＞ Linux情報・技術・セキュリティ ＞ Dirty Frag（CVE-2026-43284 / 43500）とは何か——Copy Failの暫定策が効かない理由と未パッチ期の管理者アクション
宮崎智広 この記事の監修：宮崎智広（Linux実務・教育歴20年以上・受講者3,100名超）
2026年5月8日（KST）、Linuxカーネルにまた新しいローカル権限昇格（LPE）の脆弱性が公表されました。

通称は「Dirty Frag」。CVE番号は2件チェーンで、CVE-2026-43284（xfrm-ESP / IPsec ESP処理）とCVE-2026-43500（RxRPC）です。発見者は Hyunwoo Kim 氏（@v4bel）。oss-security メーリングリストでの正式公開は 2026-05-08 03:56 KST。embargo中に第三者が公開コミットからn-day再構築してしまい、結果として早期公開に踏み切ったというのが今回の経緯です。

記事を書こうと決めたのは、Copy Fail（CVE-2026-31431）の続報を待っている読者が周りに何人もいたからです。Copy Fail公開からわずか9日。3週連続でLinuxカーネルのLPEが出てきている。20年以上Linuxサーバーの現場にいますが、ここまで間隔が詰まる時期は記憶にありません。

先に結論から書きます。Copy Failで打った algif_aead のブラックリストは、Dirty Frag には効きません。入口のモジュールが違うからです。「先週やったから大丈夫」と思っているサーバーは、もう一度棚卸しが必要です。

この記事のポイント
  • Dirty Frag は CVE-2026-43284（xfrm-ESP）と CVE-2026-43500（RxRPC）の2件チェーン。Linux 4.11 系以降のほぼ全主流カーネルが対象です。
  • Debian、AlmaLinux、Amazon Linux、SUSE は配布開始済（2026-05-08〜09）。RHEL と Ubuntu は本記事執筆時点（2026-05-10）で公式パッチ未配布、bulletin と CVE tracker の運用状態のみです。
  • Copy Fail で打った algif_aead ブラックリストは Dirty Frag には無効。入口モジュールが esp4 / esp6 / rxrpc に変わっています。
  • 未パッチ期に管理者がやれることは、カーネル更新最優先・必要なら esp4/esp6/rxrpc 無効化・最小権限と局所化（コンテナ隔離・SSHアクセス制限・SELinux強制）の3点に絞れます。
  • Dirty Pipe → Copy Fail → Dirty Frag。3週連続のカーネルLPE公開は、運用現場に「カーネル更新を後回しにできない時代」を突きつけています。

Dirty Frag（CVE-2026-43284 / 43500）とは何か——Copy Failの暫定策が効かない理由と未パッチ期の管理者アクション
「このままじゃマズい」と感じていませんか？
参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
図解60P／登録10秒／解除も3秒 ／ 詳細はこちら

Dirty Frag（CVE-2026-43284 / 43500）とは何か

2件のCVEで構成される「チェーン型」の脆弱性

Dirty Frag は単体のCVEではありません。Linux カーネルの異なるサブシステムに同根のバグが潜んでいたという発表で、CVE-2026-43284（xfrm-ESP / IPsec ESP）と CVE-2026-43500（RxRPC）の2件がチェーンとして公表されました。

発見者は Hyunwoo Kim 氏（ハンドルネーム V4bel、@v4bel）。oss-security メーリングリストでの正式投稿は 2026-05-08 03:56 KST、UTC換算では 2026-05-07 18:56 です。スレッドのタイトルは「Dirty Frag: Universal Linux LPE」。

公開のきっかけはやや異例です。本来は embargo 中で各ディストリビューターが調整中だったところに、第三者（SiCk氏）が kernel.org の公開コミットから n-day 再構築の経緯を投稿してしまい、Hyunwoo Kim 氏側が embargo を破棄して正式公開したかたちです。詳細は SiCk 氏の oss-security 投稿「Copy Fail 2 / Dirty Frag — n-day from public commit, not embargo break」に整理されています。

2件のCVEの位置づけ

それぞれの一次情報からスコアと素性を整理します。

項目 CVE-2026-43284 CVE-2026-43500
サブシステム xfrm-ESP（IPsec ESP処理）/ esp4・esp6 RxRPC（AFS分散ファイルシステム用RPC）/ rxrpc
NVD公開日 2026-05-08 2026-05-10時点 RESERVED（NVD未掲載）
CVSS Base 7.8 HIGH（CISA-ADP評価） 8.8 Important（SUSE評価）
CVSSベクター AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
CWE CWE-123（Write-what-where Condition） NVD未掲載のため未公開
影響カーネル Linux 4.11 〜 7.0.5（複数レンジ） 4.11 系以降（Ubuntu CVE tracker準拠）

両者ともローカル権限昇格（LPE）。ローカルの一般ユーザー権限から root を取られるタイプの脆弱性です。

「Dirty Frag」という命名の由来（防御側が知っておきたい範囲で）

「Dirty Frag」の由来を、攻撃手順の解説に踏み込まずに、防御の判断材料として必要な範囲で書きます。

鍵になるのは「paged frag を含むネットワーク skb（socket buffer）」です。Linuxカーネルでは、ネットワークパケットを保持するデータ構造として skb を使っており、ペイロードがページ単位で分散配置されている状態を「paged frag」と呼びます。CVE-2026-43284 の NVD 記述によれば、IPv4 / IPv6 の datagram パスでは、TCP と異なり paged frag に「shared」フラグが付かないケースがあり、そのまま ESP の入力経路で in-place 復号が走ると、共有された skb の frag に対して書き込みが起きてしまう、と説明されています。修正は shared frag に適切なフラグを付け、ESP 入力経路を copy-on-write へフォールバックさせる、というものです。

CVE-2026-43500 はこれと同根で、Ubuntu CVE tracker の修正コミットメッセージに「rxrpc: Also unshare DATA/RESPONSE packets when paged frags are present」と書かれている通り、RxRPC 側でも paged frag を含む DATA/RESPONSE パケットの unshare 漏れが残っていた、という構図です。

要するに、「フラグが付いていないせいで、共有されたメモリページに書けてしまう」。これが「Dirty Frag」の名前の由来であり、Dirty Pipe / Copy Fail と同じ「メモリの共有関係を読み違えて、本来書いてはいけない場所に書いてしまう」系譜の最新ケースだと理解しています。

本記事では攻撃手順の詳細やPoCコードには一切触れません。すでに発見者の公式リポジトリ（github.com/V4bel/dirtyfrag）と dirtyfrag.io でコードは公開されていますが、防御啓発記事としてはそこに踏み込む必要はないと判断しました。

影響を受けるカーネルバージョン

Linux 4.11 系以降がほぼ全該当

CVE-2026-43284 の CISA-ADP 記載によれば、影響開始は Linux カーネル 4.11 系からです。4.11 は 2017年 5月にリリースされたバージョンで、ここから 7.0 直前までの mainline / longterm / stable 全系列が影響圏内に入っています。

2026-05-10 時点での kernel.org の状況をまとめると、こうなります。

  • mainline: 7.1-rc2（2026-05-03 リリース）
  • stable: 7.0.5（2026-05-08）
  • longterm: 6.18.28 / 6.12.87 / 6.6.138 / 6.1.172 / 5.15.206 / 5.10.255（いずれも 2026-05-08 一斉リリース）
「longterm 各系列が同日に出ている」のがポイントです。Dirty Frag のために kernel.org が一斉に修正取り込みリリースを切ったかたちで、Greg Kroah-Hartman 氏のリリースアナウンスからもその意図は読み取れます。

「自分のカーネルが該当するか」を1コマンドで見る

まず手元のサーバーで、走っているカーネルのバージョンを確認します。

$ uname -r
5.15.0-119-generic
5.15 系で 5.15.206 未満、6.1 系で 6.1.172 未満、6.6 系で 6.6.138 未満……というふうに、自分の系列のパッチ済バージョンを下回っていれば該当です。Ubuntu のようなディストロ独自パッケージング表記の場合は、`apt changelog linux-image-$(uname -r)` で「CVE-2026-43284」「CVE-2026-43500」を grep する方が確実だと思います。

注意点として、4.11 より前のカーネルが残っているサーバーは、Dirty Frag は踏まないものの、別の理由でとっくに更新が必要な状態です。今回の機会に棚卸しをした方がいいです。


Dirty Frag（CVE-2026-43284 / 43500）とは何か——Copy Failの暫定策が効かない理由と未パッチ期の管理者アクション - 解説1

ディストロ別パッチ提供状況（2026-05-10時点）

配布済 / 配布準備中の二極化

ここが今回の記事で最も日々動いている箇所です。本記事執筆時点（2026-05-10）の整理を出しますが、本番に当てる前には必ず各ディストロの公式アドバイザリで最新状態を再確認してください。

ディストロ 状況 備考
Debian sid / trixie / bookworm / bullseye 配布済 DSA-6253-1（trixie）/ DSA-6258-1（bookworm）/ DLA-4572-1（bullseye）/ DLA-4574-1（bullseye linux-6.1）
AlmaLinux 8 / 9 / 10 配布済（2026-05-08 15:22 UTC） AL8: kernel-4.18.0-553.123.2.el8_10 以降 / AL9: kernel-5.14.0-611.54.3.el9_7 以降 / AL10: kernel-6.12.0-124.55.2.el10_1 以降
Amazon Linux 2 / 2023 配布済（2026-05-09発番） ALAS2-2026-3302、ALAS2KERNEL-5.10/5.15/5.4-2026-***、ALAS2023-2026-1693/1694/1695
SUSE（一部） 配布済 / 一部 In progress SUSE-SU-2026:1778-1（2026-05-08）。SLE Real Time 15 SP7 / SUSE Liberty Linux 8/9 / SLE Live Patching 15 SP7 などは Released、SLES 15 SP6-LTSS 等は In progress
Red Hat Enterprise Linux 8 / 9 / 10 未配布（bulletin のみ） RHSB-2026-003 で「Investigation ongoing / Red Hat is expediting fix releases」、RHSA は未発番
Ubuntu 14.04〜26.04 LTS / 25.10 未配布（USN未発番） CVE tracker は priority High、"Needs evaluation" 状態。緩和策ブログを案内

配布済の3つを使っている人は、迷わず更新

Debian / AlmaLinux / Amazon Linux を運用している人は、判断は単純です。

# Debian / Ubuntu 系
$ sudo apt update
$ sudo apt install --only-upgrade linux-image-generic linux-headers-generic
# 再起動
$ sudo reboot

# AlmaLinux / RHEL クローン
$ sudo dnf upgrade kernel kernel-core
$ sudo reboot

# Amazon Linux 2023
$ sudo dnf update kernel
$ sudo reboot
このとき、「新カーネルがインストールされた」と「メモリ上で動いている」は別であることに注意してください。`uname -r` の出力が新しくなるのは再起動後です。再起動枠が即決できない本番機では、後述する未パッチ期の管理者アクションを並行で打ちます。

RHEL と Ubuntu は「日々動く」期間に入る

RHEL と Ubuntu については、本記事執筆時点で公式パッチ未配布です。Red Hat は RHSB-2026-003 を「Investigation ongoing」「expediting fix releases」と書いており、確定パッチは展開中。Ubuntu は CVE tracker で priority High の "Needs evaluation" 状態で、USN（Ubuntu Security Notice）の発番待ちです。

"Needs evaluation" は CVE tracker の運用状態であり、「未対応」を意味しません。USN 発番のキューに乗っている状態です。それでも、本番機に対してすぐに当てられるパッケージが手元に届かないのは事実なので、RHEL / Ubuntu 利用者は未パッチ期の対応を並行で進める必要があります。後段で具体策を書きます。

Copy Fail の暫定策が Dirty Frag に効かない理由

「先週ブラックリストしたから大丈夫」が一番危ない

Copy Fail（CVE-2026-31431）の記事で、当日打てる緩和策として algif_aead モジュールのブラックリストを案内しました。`/etc/modprobe.d/disable-algif-aead.conf` で algif_aead をロード拒否し、`rmmod` で解除する、というものです。

この手法は Copy Fail には極めて有効でした。AF_ALG ソケット → algif_aead → 暗号処理という経路を入口で塞げば、攻撃の起点が成立しないからです。

しかしDirty Frag には効きません。入口モジュールが違うからです。

モジュール経路の違いを並べてみる

両者の入口モジュールを並べると、こうなります。

脆弱性 入口モジュール 使うサブシステム 緩和策の効き
Copy Fail（CVE-2026-31431） algif_aead / af_alg AF_ALG ソケット型カーネル暗号インターフェース algif_aead ブラックリストで塞げる
Dirty Frag CVE-2026-43284 esp4 / esp6 xfrm-ESP（IPsec ESP の入力経路） algif_aead ブラックリストでは効かない。esp4 / esp6 を塞ぐ必要
Dirty Frag CVE-2026-43500 rxrpc RxRPC（AFS分散ファイルシステム用RPC） algif_aead ブラックリストでは効かない。rxrpc を塞ぐ必要

Copy Fail はユーザー空間 → カーネル暗号への入口（AF_ALG）に穴がありました。Dirty Frag はネットワーク受信パス（IPsec ESP / RxRPC）に穴があります。経路がそもそも違うので、algif_aead を閉じても、esp4 / esp6 / rxrpc 経由のパケット処理にはまったく影響しません。

ここを混同したまま「先週やったから大丈夫」と判断するのが、今回いちばん危ない誤解だと思います。

Dirty Frag に効く未パッチ期の暫定策

oss-security MLでHyunwoo Kim氏が公開している即時緩和コマンドは次の通りです（防御目的のため記録）。

# /etc/modprobe.d/dirtyfrag.conf を作成して、3モジュールをロード拒否に
$ printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' | \
    sudo tee /etc/modprobe.d/dirtyfrag.conf

# すでにロード済みのモジュールは外す
$ sudo rmmod esp4 esp6 rxrpc 2>/dev/null
ただし、この手段にははっきりした副作用があります。

  • esp4 / esp6 を無効化すると、IPsec 通信が止まります。サイト間VPN、リモートアクセスVPN、コンテナ間IPsec通信などを使っている環境では、業務通信そのものが落ちます。
  • rxrpc を無効化すると、AFS（Andrew File System）が止まります。AFSは現代の一般的な業務サーバーでは使っていないことが多いため、こちらは止めても影響が限定的なケースが多いと思いますが、必ず自社環境で確認してから打ってください。
私自身の手元のサーバーで言えば、IPsec を業務で使っているのは特定の1セグメントだけなので、それ以外のサーバーでは esp4 / esp6 / rxrpc を全部止めて、IPsec を使っているサーバーだけは「IPsec を残す代わりに別の防御を厚くする」運用を採用しました。

Red Hat の RHSB-2026-003 では、IPsec を残したい場合の追加緩和として、`user.max_user_namespaces=0` で非特権ユーザー名前空間を無効化する手段が紹介されています。これは「攻撃者が一般ユーザー権限から名前空間を作って xfrm を触る」経路を塞ぐ意味があります。ただし RxRPC 側はこれでは塞がりません。複数の防御を組み合わせる前提です。

Dirty Pipe → Copy Fail → Dirty Frag という系譜

3つに共通する「メモリ共有の読み違え」

Dirty Frag を単体の事故と見ても伝わるのですが、過去の脆弱性と並べると、Linux カーネルが繰り返し同じパターンで踏んでいるのが見えてきます。

通称 主なCVE 公表年 本質
Dirty Pipe CVE-2022-0847 2022年 パイプの merge 機構で「書き込み禁止のはずのページ」に書けてしまうバグ
Copy Fail CVE-2026-31431 2026年4月 algif_aead の in-place 最適化で page cache の SetUID バイナリに書けてしまうバグ
Dirty Frag CVE-2026-43284 / 43500 2026年5月 paged frag を含む skb の shared フラグ漏れで共有メモリに書けてしまうバグ

3つに共通するのは「本来読むだけのはずのメモリに、共有関係の管理ミスで書き込みが起きてしまう」という構造です。Dirty Pipe はパイプ機構、Copy Fail はカーネル暗号インターフェース、Dirty Frag はネットワーク受信パス。サブシステムは違うのに、同じ「共有関係を読み違えて in-place 操作が走る」という穴が、別の場所に別の格好で潜んでいた。

「最適化のための共有」が繰り返し穴になる

Linux カーネルでは、性能のためにメモリコピーを減らす最適化が至る所に入っています。pipe の merge、AF_ALG の in-place、xfrm-ESP の paged skb。いずれも「同じメモリを複数の経路から読み書きする」ことで高速化を狙った機構です。

ここに「共有していることを忘れて書き込んでしまう」という見落としが生まれると、ローカル権限昇格のドアが開いてしまう。Dirty Pipe からの4年で、Linux カーネル全体としてこの問題への向き合い方は確実に進んでいるはずなのに、それでも別のサブシステムで同じ構造の穴が見つかる。これは、攻撃者側にとっては「狙うべきパターンが分かっている」状況であり、防御側にとっては「同種の穴がまだ眠っている前提で備える」局面に入ったということだと思います。

受講生のひとりに「Dirty Pipe ってもう4年も前ですよね」と言われて、確かにそうだと思いました。当時は「歴史的な大物バグ」として扱われていた Dirty Pipe が、いまは「3週連続で出てくる Linux カーネル LPE 系譜の起点」として位置づけ直されている。これは現場の感覚として、覚えておく価値があります。


Dirty Frag（CVE-2026-43284 / 43500）とは何か——Copy Failの暫定策が効かない理由と未パッチ期の管理者アクション - 解説2

未パッチ期の管理者アクション

優先順は「カーネル更新 → モジュール無効化 → 局所化」

ここまでで状況の整理は終わりました。ここからは、本記事執筆時点（2026-05-10）の段階で本番機の管理者がやるべきことを、優先順に並べます。

1. パッチが出ているなら、迷わず適用する

Debian / AlmaLinux / Amazon Linux / SUSE 利用者は、これが最優先です。

# 適用前に、現状のカーネルを記録
$ uname -r
$ rpm -q kernel  # RHEL系
# または
$ dpkg -l | grep linux-image  # Debian/Ubuntu系

# changelogで明示的にCVEが含まれることを確認してから適用
$ rpm -q --changelog kernel | grep -E "CVE-2026-43284|CVE-2026-43500"
# Debian/Ubuntu の場合
$ apt changelog linux-image-$(uname -r) | grep -E "CVE-2026-43284|CVE-2026-43500"
「新カーネルがインストールされた」ことと「Dirty Frag パッチが入っている」ことは必ずしも一致しません。changelog で CVE 番号を grep して明示的な対応を確認してから、再起動枠を取りに行く方が筋がいいと思います。

私はステージング環境で先に当てて1日様子を見てから、本番機に展開する運用を取っています。今回も IPsec を業務で使っている環境では、再起動後に IPsec 接続が正しく戻るかどうかを確認する手順を別途組みました。

2. RHEL / Ubuntu 利用者は、esp4 / esp6 / rxrpc を一時停止できないか検討する

公式パッチ未配布期の RHEL / Ubuntu 利用者は、業務影響の有無を確認したうえで、3モジュールの一時停止を検討します。

# まず、現在ロードされているか確認
$ lsmod | grep -E "esp4|esp6|rxrpc"

# IPsec を使っているか確認
$ sudo ip xfrm policy
$ sudo ip xfrm state
# ↑ 何も出なければ IPsec を使っていない可能性が高い

# AFS を使っているか確認
$ mount | grep afs
# ↑ 何も出なければ AFS を使っていない
`ip xfrm policy` と `ip xfrm state` の両方が空、`mount | grep afs` も空であれば、esp4 / esp6 / rxrpc を止めても直接的な業務影響は出にくいと判断できます。あとは、コンテナ環境やオーバーレイネットワーク（一部の Kubernetes ネットワークプラグインは IPsec を使う構成があります）で間接的に依存していないか、自社のネットワーク図で確認します。

判断ができたら、Hyunwoo Kim 氏の公開した即時緩和コマンドで止めます。

$ printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' | \
    sudo tee /etc/modprobe.d/dirtyfrag.conf
$ sudo rmmod esp4 esp6 rxrpc 2>/dev/null
これで Dirty Frag のエクスプロイトに必要なモジュール経路は塞がります。「全部のサーバーで一括で止める」のではなく、サーバーごとに業務影響を確認しながら順次止めていく方が安全です。

3. IPsec を残したいサーバーは、攻撃者の入口を絞る

サイト間VPNや業務通信で IPsec を止められないサーバーでは、esp4 / esp6 を残す代わりに、攻撃者がローカル一般ユーザー権限を取りにくくする方向で防御を厚くします。具体的には次のような組み合わせです。
  • 非特権ユーザー名前空間の無効化: `sysctl -w user.max_user_namespaces=0`（Red Hat RHSB-2026-003 推奨）。永続化は `/etc/sysctl.d/` 配下に書きます。
  • SSH のローカルアクセス制限: 業務上必要な踏み台経由・特定IPからのみに絞る。`AllowUsers` / `AllowGroups` で対象ユーザーを最小化。
  • SELinux 強制モード（enforcing）を解除している環境は、戻せないか再検討。RHEL / AlmaLinux では強制モードが Dirty Frag 系の権限昇格の事後影響を限定する側に効きます。
  • コンテナ隔離の徹底: コンテナ内の一般ユーザーから rootful な攻撃面（IPsec モジュール、xfrm 周り）に到達できないように、rootless container や user namespaces の運用を見直す。
  • ローカルアカウントの棚卸し: 不要なシェルログイン可能アカウントを `/sbin/nologin` に切る。LPE は「ローカル一般ユーザー」が前提なので、入口を減らすこと自体が直接的な防御になります。
これらは Dirty Frag 専用の対策ではなく、ローカル権限昇格脆弱性に対する一般的なハードニングです。「カーネル更新が遅れる前提で、入口側を絞る」という考え方で組み合わせます。

4. ライブパッチの導入を、本気で再検討する

Dirty Frag のような「再起動が必要だが、再起動枠がすぐに取れない本番機」のために、Ubuntu Pro の Livepatch、RHEL の kpatch、SUSE の kGraft、サードパーティの KernelCare などのライブパッチがあります。

受講生から「Livepatch は課金して元が取れますか」と聞かれた時、これまでは「年に1〜2回の緊急対応で十分元が取れます」と答えていました。Dirty Pipe → Copy Fail → Dirty Frag の3週連続を見て、その答えはもう少し強くなりました。「3週連続で来る前提なら、迷っているコストの方が高い」です。

ライブパッチも万能ではなく、対応カーネルの範囲やパッチ提供の遅延はあります。それでも、本番機の再起動枠が四半期に1回しか取れない環境では、選択肢として真剣に検討する局面に入ったと思います。

3週連続の LPE 公開という運用負荷

「カーネル更新を後回しにできない時代」がはっきり見えた

Copy Fail（2026-04-29）から Dirty Frag（2026-05-08）まで、わずか9日。その前の Dirty Pipe（2022年）からは4年経っているので、「ペースが速くなった」と感じる主観は事実に裏打ちされています。

これが運用現場に何を突きつけているか。私の整理では、3つあります。

1. 「LTSだから5年放置」は完全に通用しない

LTS は「メジャーバージョンを5年据え置ける」のであって、「マイナーバージョンを更新しなくていい」では断じてありません。Dirty Frag のために longterm 全系列が同日にリリースを切ったという事実は、「上流が動いた瞬間に手元も動かす」運用が標準になりつつあることを意味しています。

私自身、SE時代に「LTSなので5年放置していい」と勘違いしていたサーバーがありました。今思うと、あれは LTS の意味の誤解です。LTS が保証しているのはメジャーバージョン据え置きであって、セキュリティ修正の据え置きではありません。

2. 「再起動枠の取れなさ」が直接的な脆弱性になる

Dirty Frag のパッチを当てるには再起動が必要です。Copy Fail も同じでした。Dirty Pipe も同じでした。「再起動枠が取れない本番機」は、それ自体が脆弱性として扱われる時代に入っています。

ここで効くのは、Livepatch の検討と同時に、「再起動枠そのものを増やす」ことです。月1回のメンテナンスウィンドウを取れる体制、ロードバランサー配下で1台ずつ再起動できる構成、Blue/Green デプロイで切り替えられる本番系。これらは「いつか整えたい改善」ではなく、「いま整えないと脆弱性が積み重なる」改善になっています。

3. AI監査ツール時代の前提で運用を組む

Copy Fail は Theori 社の AI 監査ツール「Xint Code」が掘り起こしたバグでした。Dirty Frag は Hyunwoo Kim 氏個人の研究成果ですが、ML 上でも「公開コミットからの n-day 再構築」という第三者解析が同時並行で動きました。

AI と人間の研究者の両方から「過去の最適化が穴になっている」掘り返しが進む。これは仮説ではなく、ここ数週間で起きている事実です。同じ作りの「最適化・高速化・省メモリ化」は他のサブシステムにも眠っている前提で、向こう数年の運用を組み立てる必要があると思います。


Dirty Frag（CVE-2026-43284 / 43500）とは何か——Copy Failの暫定策が効かない理由と未パッチ期の管理者アクション - まとめ

まとめ：今日できることと、次に来るものへの備え

今日できることのチェックリスト

長くなったので、今日の作業に落とし込めるチェックリストで締めます。

  • `uname -r` で現行カーネルを確認し、自系列のパッチ済バージョンと突き合わせる
  • Debian / AlmaLinux / Amazon Linux / SUSE 利用者は、changelog で CVE-2026-43284 / 43500 が含まれることを確認してから適用 → 再起動枠の確保
  • RHEL / Ubuntu 利用者は、IPsec / AFS の利用状況を `ip xfrm policy` と `mount | grep afs` で確認し、影響がなければ esp4 / esp6 / rxrpc を一時停止
  • IPsec を残すサーバーは、`user.max_user_namespaces=0`、SSH アクセス制限、SELinux 強制モード、ローカルアカウント棚卸しの組み合わせで入口を絞る
  • ライブパッチ（Livepatch / kpatch / kGraft / KernelCare）の導入可否を、3週連続 LPE の前提で再検討
  • Copy Fail で打った algif_aead ブラックリストを残しているサーバーは、Dirty Frag に効かないことを再確認のうえ、対応の追加を漏らさない

次に来るものへの備え

Dirty Pipe → Copy Fail → Dirty Frag は、たぶん、ここで終わりません。同じ「メモリ共有の読み違え」系のバグが他のサブシステムでも掘り起こされる前提で、運用側の備えを整えておくのが現実的だと思います。

具体的には次の3点です。

  • カーネル更新を「3ヶ月に1回」運用ルールに格上げする。`apt-mark hold` で止めているなら、解除して動作確認を運用フローに組み込む。
  • HWE と GA を意図して選び分ける。Ubuntu LTS の HWE / GA、RHEL の標準カーネル / 拡張サポート。なんとなくデフォルトのまま運用しているサーバーが、いま一番危ない。
  • 再起動枠の確保を「やりたいこと」から「やらなきゃいけないこと」に移す。月1メンテナンスウィンドウ、ロードバランサー配下のローリング再起動、Blue/Green。
本記事執筆時点（2026-05-10）で、RHEL / Ubuntu の公式パッチは未配布です。本サイトでは、状況の進展に合わせて記事末「更新履歴」欄に追記していきます。Dirty Frag だけでなく、次に同種のバグが出た時にもなるべく早くお届けします。

参考

3週連続のカーネル LPE。「再起動枠が取れない本番機」を、自信を持って守れていますか？

uname -r、ip xfrm policy、modprobe.d、HWE/GA選択、ライブパッチの判断。記事で読むだけでなく、実機で繰り返し手を動かすことで初めて身につきます。
ネットの切れ端の情報をコピペするだけでなく、現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル（図解60P）』を完全無料でプレゼントしています。

今すぐ無料でダウンロード（登録10秒） ＞＞ 図解60P『Linux入門マニュアル』を受け取る

※ 「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。

関連記事

無料メルマガで学習を続ける

Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。

登録無料・いつでも解除できます

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。

登録10秒／合わなければ解除3秒 ／ 詳細はこちら

Linux無料マニュアル（図解60P） 名前とメールで30秒登録
宮崎 智広

この記事を書いた人

宮崎 智広（みやざき ともひろ）

株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として15年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。

趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。

Linux無料マニュアル（図解60P） 名前とメールで30秒登録