ＨＯＭＥ ＞ リナックスマスター.JP 公式ブログ ＞ Linux情報・技術・セキュリティ ＞ Fragnesia（CVE-2026-46300）｜パッチが新たな穴を作った2026年5月のLinuxカーネル事件
この記事の監修：宮崎智広（Linux実務・教育歴20年以上・受講者3,100名超）
/usr/bin/su や /etc/passwd を直接改変して root を取られる類です。先に結論をお伝えします。「Dirty Fragパッチを当てた」だけでは Fragnesia に対して無力です。パッチを当てて再起動したけど、もう一度確認が必要です。
この記事のポイント
- Fragnesia（CVE-2026-46300）は Dirty Frag のパッチ起因で表面化した新しいLPE。発見者 William Bowling 氏（V12）、公開2026-05-13。
- 根本原因は
skb_try_coalesce()がSKBFL_SHARED_FRAGを伝播しない欠陥。少なくとも2013年から潜伏。 - race condition 不要で page cache を決定論的に書き換えられる。Dirty Frag より悪用が安定。
- Dirty Fragパッチ済カーネルでも Fragnesia は別途未パッチ。RHEL / Ubuntu / Debian は5/15時点で公式パッチ未配布。
- Dirty Frag 公式緩和（esp4 / esp6 / rxrpc 無効化）は Fragnesia にも有効。「Dirty Frag対応済」と「Fragnesia対応済」を分けて棚卸しする必要がある。
「このままじゃマズい」と感じていませんか？
参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
図解60P／登録10秒／解除も3秒 ／
詳細はこちら
Fragnesia（CVE-2026-46300）とは何か
Dirty Fragのパッチが「次のバグ」を生んだ
Fragnesia の特殊さはここに尽きます。Dirty Frag を塞ぐためのパッチを当てた結果、別のバグが表面化した。これが Fragnesia です。発見者 William Bowling 氏（V12 security team）、公開 2026-05-13、Help Net Security と SecurityWeek が同日付で報じました。AlmaLinux 公式 blog の記述によれば、Fragnesia は「Dirty Frag を修正するパッチの一つが意図せず表面化させた、別の同根バグ」です。NVD では 2026-05-15 時点でまだ "RESERVED" 状態のため CVSS の正式値は未掲載で、Tenable と Ubuntu CVE tracker が暫定的に CVSS 7.8 HIGH と評価しています。2件のチェーンに「3件目」が追加された格好
先週の Dirty Frag は CVE-2026-43284（xfrm-ESP）と CVE-2026-43500（RxRPC）の2件チェーン。そこに Fragnesia が加わり、Red Hat の RHSB-2026-003 は3CVE合算 bulletin に更新されました（2026-05-13 17:37 最終更新）。| CVE | 通称・分類 | 公開日 | 状態 |
|---|---|---|---|
| CVE-2026-43284 | Dirty Frag 本体（xfrm-ESP） | 2026-05-08 | CVSS 8.8 HIGH（kernel.org）／7.8 HIGH（CISA-ADP） |
| CVE-2026-43500 | Dirty Frag 同根（RxRPC） | 2026-05-11 NVD公開 | CVSS 7.8 HIGH、CWE-787 |
| CVE-2026-46300 | Fragnesia（XFRM ESP-in-TCP） | 2026-05-13 | NVD は RESERVED、暫定 CVSS 7.8 HIGH |
3つとも Linux カーネルのローカル権限昇格脆弱性で、踏み台・コンテナ内シェル・SSHアカウント奪取後など、普通に悪用される可能性があります。
「Dirty Frag対応済 ≠ Fragnesia対応済」
実務上いちばん大事なのはここです。Dirty Frag のパッチを当てて再起動した。だから「対応完了」で問題ないと思いがちですが、じつはそうではありません。AlmaLinux の公式 blog にはっきり書いています。「Dirty Frag パッチ済カーネルは Fragnesia には未対応」。ただし「Dirty Frag の公式緩和コマンド（esp4 / esp6 / rxrpc 無効化）は Fragnesia にも効果がある」。つまり、パッチ済の方が緩和策を解除しているぶん、緩和策をまだ残しているサーバーよりも危ない、というねじれが起きています。
影響範囲とパッチ提供状況（2026-05-15時点）
Fragnesia の影響範囲は Dirty Frag と同じ
Tenable と AlmaLinux blog の記述を突き合わせると、Fragnesia の影響範囲はDirty Frag と同じ Linux カーネルバージョン群です。Linux 4.11 系以降のほぼ全ての mainline / longterm / stable 系列が該当します。注意点は根本原因の欠陥が少なくとも2013年から潜伏していたとされる点（Help Net Security）。Dirty Frag のパッチがコードパスを変えたことで「これまで踏まれていなかった経路」を踏むようになり Fragnesia として顕在化した、という構図です。ディストロ別の対応状況
2026-05-15 時点の状況を表にします。本番投入前には必ず各ディストロの公式アドバイザリで最新状態を再確認してください。| ディストロ | 状況 | 備考 |
|---|---|---|
| AlmaLinux 8 / 9 / 10 | 配布済（2026-05-13） | AL8: kernel-4.18.0-553.124.3.el8_10 以降 / AL9: kernel-5.14.0-611.54.5.el9_7 以降 / AL10: kernel-6.12.0-124.56.3.el10_1 以降 |
| Fedora | 配布済（Tenable記載） | 常用ローリングのため最新カーネルに反映済 |
| CloudLinux | 配布済（KernelCare経由） | ライブパッチ対応 |
| Red Hat Enterprise Linux 8 / 9 / 10 | 未配布（bulletin のみ） | RHSB-2026-003 に3CVE合算掲載、RHSA は未発番（"expediting fix releases"） |
| Ubuntu 20.04～26.04 LTS | 未配布（USN未発番） | CVE tracker priority High、"Needs evaluation"。netdev tree に修正が存在 |
| Debian sid / trixie / bookworm / bullseye | 未配布（unfixed） | DSA / DLA 未発番。security-tracker は vulnerable と明記 |
Dirty Frag では配布の代表格だった Debian が Fragnesia ではまだ未配布で並んでいるのが今回のポイントです。「先週速かったから今週も速い」とは限らないと、改めて意識する必要があります。
技術的本質：2013年から眠っていたフラグ伝播漏れ
「コーレッシング時にフラグが伝わらない」という構造
Fragnesia の根本原因を、防御の判断材料として必要な範囲で書きます。鍵になるのはskb_try_coalesce() という関数です。Linux カーネルは性能のため、複数の socket buffer（skb）を1つに統合（コーレッシング）する処理を入れています。受信側で細切れに届いたパケットを1つの大きな buffer に纏めて上位レイヤーに渡すための最適化です。纏める元の buffer に
SKBFL_SHARED_FRAG フラグが立っていた場合、その buffer の paged fragment は外部のメモリ（page-cache のページなど）に背中合わせで載っていることを示します。コーレッシング先の新しい buffer にもこのフラグを伝播させないと、カーネルは「これは外部バックの fragment だ」という事実を忘れます。Fragnesia はこのフラグ伝播が抜けていた欠陥です。本来「読むだけ」のはずの page cache のページに対して、カーネルが書き込み可能だと誤認します。攻撃者はこの誤認を使って /usr/bin/su や /etc/passwd の page cache を書き換えに行きます。race condition 不要・決定論的が怖い
Dirty Frag では攻撃成立に race condition が絡んでいたため、タイミングがズレれば失敗し、攻撃者は何度もリトライする必要がありました。Fragnesia には race condition が要らないとされ、決定論的に page cache を書き換えに行けるため攻撃の安定度が高い。検知側から見ると、リトライによる失敗イベントというノイズが出にくく、気づきにくい性質を持つ可能性があります。なお本記事では攻撃手順や PoC コードには触れません（v12-security の PoC は公開済みですが、防御啓発記事として踏み込みません）。Linux管理者の検知と対応（5/15時点でできる対策）
1. 「Dirty Frag対応済」リストを Fragnesia 軸で再点検する
先週 Dirty Frag 対応した管理対象サーバー一覧を、もう一度確認します。次の3つを追加します。- Dirty Frag パッチ済か（5/8～13のあいだに当てたか）
- Fragnesia パッチ済か（5/13以降に当てたか）
- 緩和策（esp4/esp6/rxrpc 無効化）を維持しているか
2. ディストロ別の優先順位
ディストロごとに5/15時点で打つ手が変わります。# AlmaLinux 8/9/10（パッチ配布済） $ sudo dnf clean metadata && sudo dnf upgrade kernel kernel-core && sudo reboot $ rpm -q --changelog kernel | grep -E "CVE-2026-46300|Fragnesia" # RHEL / Ubuntu / Debian（パッチ未配布）-- 緩和策の維持・追加で対応 $ lsmod | grep -E "esp4|esp6|rxrpc" $ cat /etc/modprobe.d/dirtyfrag.conf
3. 緩和策の再投入（IPsec / AFS を使っていないサーバー限定）
Dirty Frag 公式緩和（Fragnesia にも有効）の再投入手順です。# IPsec / AFS を使っていないことを確認（すべて空なら止めても影響出にくい） $ sudo ip xfrm policy; sudo ip xfrm state; mount | grep afs # 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
4. IPsec を残すサーバーは、page cache のドロップを定期化する
AlmaLinux の Fragnesia blog 案内の追加緩和に page cache の強制ドロップがあります。sync && echo 3 | sudo tee /proc/sys/vm/drop_caches で改変済み page cache を退避させ、次回読み込みで disk から正しい内容を取得します。攻撃が再実行されれば再汚染されるため根本対策ではありませんが、未パッチ期間 IPsec を残すサーバーで定期実行する価値はあります。私は1台に対し30分ごとに cron で走らせる運用を入れました。5. user.max_user_namespaces=0 などの一般的ハードニングは継続
Red Hat RHSB-2026-003 推奨の非特権ユーザー名前空間無効化は、Fragnesia にも入口を絞る効果があります。echo "user.max_user_namespaces=0" | sudo tee /etc/sysctl.d/99-disable-userns.conf && sudo sysctl --system。ただしコンテナや一部の Snap / Flatpak で必要なケースがあるため、本番投入前にステージングで挙動を確認してください。「パッチを当てた直後が危ない」という新しい局面
パッチが穴を作る時代
これまで「パッチを早く当てるのが正義」は疑う余地がない絶対的ルールでした。Dirty Frag → Fragnesia の流れは、その前提を崩しつつあります。パッチを当てた瞬間に、別の穴が表面化することがある。2013年から潜伏していたskb_try_coalesce() のフラグ伝播漏れは、Dirty Frag のパッチがコードパスを変えるまで現実の脅威ではありませんでした。誰も行かない経路に眠っていた穴を、緊急パッチで表面化してしまった、ということです。「カーネル更新 → 再点検」のサイクルを2段階で組む
Dirty Pipe（2022年）→ Copy Fail（2026-04-29）→ Dirty Frag（2026-05-08）→ Fragnesia（2026-05-13）。Dirty Frag から Fragnesia までは5日しか空いていません。このペースを前提にすると、カーネル更新を2段階に分けて運用する方が現実的だと思います。- 段階1: パッチが出たら速やかに当てる（従来通り）
- 段階2: パッチ適用から1週間以内に、同根バグの続報を確認する時間を業務として確保する
まとめ：Dirty Frag対応済リストを、もう一度開く
今日できることのチェックリスト
今日の作業に落とし込めるチェックリストを紹介します。- 先週の Dirty Frag 対応で作った管理対象サーバーリストを、もう一度開く
- 「Dirty Frag パッチ済」「Fragnesia パッチ済」「緩和策維持」の3点を再確認
- AlmaLinux / Fedora / CloudLinux 利用者は
dnf upgrade kernelで5/13配布パッチを当てる。changelog で CVE-2026-46300 を明示確認 - RHEL / Ubuntu / Debian 利用者は、Dirty Frag 緩和策（
/etc/modprobe.d/dirtyfrag.conf）を維持または再投入。先週解除したサーバーがいちばん危ない - IPsec / AFS を使っているサーバーは、
user.max_user_namespaces=0と SSH アクセス制限、SELinux 強制モード、ローカルアカウント棚卸しを組み合わせる - パッチ適用後1週間以内に、同根バグの続報を取りに行く時間をカレンダーに確保する
次に来るものへの備え
Dirty Pipe → Copy Fail → Dirty Frag → Fragnesia の流れがここで終わる保証はなく、skb_try_coalesce() 周辺だけでも別経路が掘り起こされる可能性があります。「パッチを当てたら終わり」ではなく「パッチ適用から1週間後に、新しい穴が表面化していないか確認する」作業を運用フローに組み込むこと。緊急パッチほど、適用後の再点検期間を業務として確保する。これが2026年の Linux サーバー運用に必要な新しい基準だと考えています。本記事執筆時点（2026-05-15）で RHEL / Ubuntu / Debian の Fragnesia 公式パッチは未配布です。状況の進展は記事末の更新履歴に追記していきます。参考
- AlmaLinux blog（CVE-2026-46300 Fragnesia）: https://almalinux.org/blog/2026-05-13-fragnesia-cve-2026-46300/
- Red Hat RHSB-2026-003: https://access.redhat.com/security/vulnerabilities/RHSB-2026-003
- Ubuntu CVE Tracker（CVE-2026-46300）: https://ubuntu.com/security/CVE-2026-46300
- Debian Security Tracker（CVE-2026-46300）: https://security-tracker.debian.org/tracker/CVE-2026-46300
- Tenable FAQ（Fragnesia）: https://www.tenable.com/blog/fragnesia-cve-2026-46300-faq-about-new-linux-kernel-xfrm-esp-in-tcp-priv-esc
- SecurityWeek（Fragnesia）: https://www.securityweek.com/new-linux-kernel-vulnerability-fragnesia-allows-root-privilege-escalation/
- NVD CVE-2026-43284（Dirty Frag）: https://nvd.nist.gov/vuln/detail/CVE-2026-43284
- NVD CVE-2026-43500（RxRPC）: https://nvd.nist.gov/vuln/detail/CVE-2026-43500
- 関連: 当サイト Dirty Frag 解説記事 / CVE-2026-43284「Dirty Frag」とLinuxサーバー管理者が今日打つべき一手
パッチを当てた瞬間に次の穴が表面化する時代。「再点検まで含めた更新運用」、自信を持って回せていますか？
uname -r、ip xfrm policy、modprobe.d、changelogでのCVE grep、page cache ドロップの定期化。記事で読むだけでなく、実機で繰り返し手を動かすことで初めて身につきます。
ネットの切れ端の情報をコピペするだけでなく、現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル（図解60P）』を完全無料でプレゼントしています。
「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。
暗記不要・1時間後にはサーバーが動く
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
登録10秒／合わなければ解除3秒 ／ 詳細はこちら
Linux無料マニュアル（図解60P）
名前とメールで30秒登録
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。
登録無料・いつでも解除できます