Fragnesia（CVE-2026-46300）をRHEL系で検知する｜auditd・Falco・eBPFで非特権ユーザーの怪しいXFRM呼び出しを掴む

ＨＯＭＥ ＞ リナックスマスター.JP 公式ブログ ＞ Linux情報・技術・セキュリティ ＞ Fragnesia（CVE-2026-46300）をRHEL系で検知する｜auditd・Falco・eBPFで非特権ユーザーの怪しいXFRM呼び出しを掴む
宮崎智広 この記事の監修：宮崎智広（Linux実務・教育歴20年以上・受講者3,100名超）

2026年5月13日、Linuxカーネルに新しい権限昇格脆弱性 Fragnesia（CVE-2026-46300、CVSS 7.8） が公開されました。XFRM ESP-in-TCP の論理バグで、非特権ユーザーがレースコンディションなしで /usr/bin/su の page cache を書き換え、root を取れます。PoCはGitHubで公開済み。

Fragnesia(CVE-2026-46300)の脆弱性概要・Dirty Fragパッチとの関係・ディストロ別パッチ運用については別記事「Fragnesia(CVE-2026-46300)の全体像とパッチ運用」で網羅しました。本記事はその実装編として、RHEL／Rocky Linux／AlmaLinux／CentOS Stream 系運用環境で auditd・Falco・eBPF を使って「非特権ユーザーの怪しいXFRM／unshare／splice 呼び出し」を掴む検知シグネチャの具体実装に絞ります。

RHEL系を運用している立場で、いま気になっているのは「パッチ」より「検知」です。Fragnesia は決定論的で失敗イベントを残さないため、auditd の標準設定だけでは痕跡を拾えません。本記事のメインは auditd・Falco・eBPF で「非特権ユーザーの怪しいXFRM／unshare／splice 呼び出し」を掴むシグネチャ実装と、パッチ適用後の page cache 事後検証です。20年以上Linuxの現場で運用してきましたが、「パッチ後に挙動がおかしい」という相談はだいたい再起動とpage cacheに行き着きます。

「このままじゃマズい」と感じていませんか？
参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
図解60P／登録10秒／解除も3秒 ／ 詳細はこちら

Fragnesia（CVE-2026-46300）のおさらいとRHEL系の現在地

Fragnesiaは XFRM ESP-in-TCP の skb_try_coalesce() が SKBFL_SHARED_FRAG フラグを伝播しない論理バグです。受信側でsocket buffer（skb）を結合したとき、結合先の buffer が「外部メモリ（page cache）に背中合わせで載っているフラグメントを持つ」事実をカーネルが忘れます。本来読み取り専用の page cache に対し、カーネル自身が書き込み可能だと誤認し、攻撃者は /usr/bin/su や /etc/passwd の page cache を書き換えて root に昇格します。

RHEL系の現在地（2026-05-19時点、私が確認できた範囲）は次のとおりです。

ディストロ状況備考
AlmaLinux 8 / 9 / 10本番リポジトリにパッチ配布済kernel-4.18.0-553.124.3.el8_10 / kernel-5.14.0-611.54.5.el9_7 / kernel-6.12.0-124.56.3.el10_1 以降
Fedora更新提供済dnf upgrade で取得可
RHEL 8 / 9 / 10順次提供中RHSAは発番途中、RHSB-2026-003 で勧告先行
Rocky LinuxAlmaLinux同等パッチ提供見込みSIG Securityのアナウンス確認推奨
CentOS Stream 8 / 9 / 10RHEL先行で順次提供stream系は早めに反映される傾向

2026年5月13日以前にリリースされたカーネルはすべて影響を受けます。サブスクリプション契約のあるRHEL本体は access.redhat.com/security/cve/cve-2026-46300 の最新errata情報を当日中に確認するのが定石です。

パッチを待つあいだのRHEL系緩和策（モジュール無効化）

パッチ前にやることは2つ。IPsec／AFS の利用棚卸しと、モジュール無効化です。AlmaLinux公式の緩和策がそのままRHEL系全体に適用できます。

まずIPsec／AFSの利用有無を確認します。

# policy/state両方が空ならIPsec ESPは未使用
sudo ip xfrm policy
sudo ip xfrm state
# AFS（rxrpc）のマウント
mount -t afs | head -5

すべて空なら、esp4／esp6／rxrpc モジュールはロード拒否してかまいません。

# /etc/modprobe.d/fragnesia.conf を作る
sudo sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/fragnesia.conf"
# 既ロード分はunload（VPN／NFS over IPsecが死ぬので影響確認必須）
sudo rmmod esp4 esp6 rxrpc 2>/dev/null || true
# page cacheをドロップ（汚染ページ排出）
sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'

注意点は2つ。IPsec ESP または AFS／rxrpc を使っているサーバーでは通信が落ちます。site-to-site VPN や IPsec で社内網に繋いでいるエッジ用途は必ず先に棚卸ししてください。もう1つ、Dirty Frag（CVE-2026-43284 / 43500）対応で同じ modprobe.d 設定を入れていた組織は、Fragnesia でも保護されると複数ソース（Tenable／Tuxcare）で確認できています。カーネルパッチのみで対応していた組織は、Fragnesia専用のパッチを別途当てる必要があります。

PR / auditd・Falcoのシグネチャ実装を腹落ちさせたい方へ

実践 bashによるサイバーセキュリティ対策 ―セキュリティ技術者のためのシェルスクリプト活用術 Paul Troncone・Carl Albing 著 / 高橋 基信 訳 / オライリー・ジャパン

ausearch・aureport のパース、ログ集約、検知ルールの組み合わせ判定など、Fragnesia の検知シグネチャをコマンドラインで「実運用」に落とすための手の動かし方を一冊で押さえ直せます。Falco YAML を書く前に bash でログを掴む土台になります。

auditdで「非特権ユーザーのXFRM／unshare／setuid遷移」を掴む

Fragnesia は決定論的（レースコンディション不要）なので、攻撃側に失敗イベントが残りません。auditd で痕跡を拾うなら、攻撃成立そのものではなく、攻撃に必要な準備行動の組み合わせを見ます。SOC Prime と Tenable FAQ 両方の着眼点を、RHEL系の auditd 文法に落とし込みます。

追跡するシステムコールは5系統。unshare／setns／clone3（namespace 分離）、NETLINK_XFRM ソケット、AF_ALG ソケット、splice、setuid バイナリの execve。このうち auditd で素直に拾えるのは namespace 系 syscall と setuid 遷移バイナリの execve です。/etc/audit/rules.d/99-fragnesia.rules を新規に作ります。

# /etc/audit/rules.d/99-fragnesia.rules
# namespace 分離系（非特権ユーザーからのuser+network unshareは要注意）
-a always,exit -F arch=b64 -S unshare -F auid>=1000 -F auid!=4294967295 -k fragnesia_unshare
-a always,exit -F arch=b64 -S setns   -F auid>=1000 -F auid!=4294967295 -k fragnesia_setns
-a always,exit -F arch=b64 -S clone3  -F auid>=1000 -F auid!=4294967295 -k fragnesia_clone3

# setuid 遷移バイナリの execve（非特権ユーザーの実行を追跡）
-w /usr/bin/su     -p x -k fragnesia_setuid
-w /usr/bin/sudo   -p x -k fragnesia_setuid
-w /usr/bin/pkexec -p x -k fragnesia_setuid

適用して結果を見ます。

# 反映
sudo augenrules --load
sudo systemctl restart auditd

# 直近1時間の検知（タグ別に件数を見る）
sudo ausearch -ts recent -k fragnesia_unshare  | aureport -x --summary
sudo ausearch -ts recent -k fragnesia_setuid   | aureport -x --summary

ポイントは -F auid>=1000。サービスアカウント（auid=0 や <1000 のシステムユーザー）を除外し、対話ログインしてきた一般ユーザーの行動だけを拾えます。SSH ログインしてきた開発者が unshare(CLONE_NEWUSER｜CLONE_NEWNET) を打ち、続けて /usr/bin/su を execve していたら、十分「呼び出して話を聞く」案件です。auditd を仕込むときの基本は「攻撃を1発で捕まえようとしない、必要な所作の組み合わせを残す」。auditd は NETLINK_XFRM や AF_ALG の socket 種別までは細かく取れません。ここから先は Falco／Tetragon の領域です。

Falcoルールで NETLINK_XFRM・AF_ALG・splice を組み合わせて見る

Falco は eBPF プローブでシステムコール引数まで踏み込めます。RHEL系ではEPEL／Sysdig公式リポジトリから dnf install falco で入り、kmod 版より modern_ebpf プローブのほうが今のRHEL系では素直に動きます。

検知の観点は「単発のシステムコール」ではなく「所作の連鎖」です。次の組み合わせが揃ったら怪しい、という発想です。

  • 非特権プロセスが unshare(CLONE_NEWUSER | CLONE_NEWNET) を発行
  • 同プロセス（または子）が NETLINK_XFRM ソケットを開く
  • かつ AF_ALG ソケットを開く
  • 通常ファイルから TCP ソケットへの splice() が続く
  • 同じソケットに対する ULP モード変更が走る

Falco ルールで完璧に書ききるのは難しいですが、「1番＋2番」「2番＋3番」「4番＋5番」のどれか2つを満たしたら通知、ぐらいの粒度に落とすと現場で回ります。Falco ルール（YAML）の骨格を載せます。

# /etc/falco/rules.d/fragnesia.yaml
- macro: unprivileged_user
  condition: (user.uid >= 1000)

- macro: xfrm_netlink_socket
  condition: (evt.type = socket and evt.arg.proto = 6 and evt.arg.domain = AF_NETLINK)
  # NETLINK_XFRM = 6

- macro: af_alg_socket
  condition: (evt.type = socket and evt.arg.domain = AF_ALG)

- rule: Fragnesia suspicious XFRM + AF_ALG by unprivileged user
  desc: 非特権ユーザーが NETLINK_XFRM ／ AF_ALG ソケットを短時間で両方開いた場合に通知
  condition: >
    unprivileged_user and
    (xfrm_netlink_socket or af_alg_socket) and
    not proc.name in (charon, strongswan, racoon, openvpn, wireguard)
  output: >
    Fragnesia 兆候: 非特権UIDが XFRM/AF_ALG socket を発行
    (user=%user.name uid=%user.uid proc=%proc.name pid=%proc.pid cmd=%proc.cmdline)
  priority: WARNING
  tags: [fragnesia, cve-2026-46300, lpe]

- rule: Fragnesia suspicious unshare + setuid exec
  desc: unshare 直後に setuid バイナリを実行している非特権プロセス
  condition: >
    unprivileged_user and
    evt.type = execve and
    proc.aname[1] in (unshare) and
    proc.exepath in (/usr/bin/su, /usr/bin/sudo, /usr/bin/pkexec)
  output: >
    Fragnesia 兆候: unshare 直後に setuid binary を execve
    (user=%user.name proc=%proc.name parent=%proc.pname cmd=%proc.cmdline)
  priority: WARNING
  tags: [fragnesia, cve-2026-46300, lpe]

「strongswan／openvpn／wireguard などVPNプロセス」を除外している点に注意してください。VPN系プロセスはXFRM netlink を正規に使うので、ここを外さないと毎分通知が飛びます。逆に言えば「VPNを使っていない・なのに NETLINK_XFRM ソケットを開く非特権プロセスがいる」状態が出たら、ほぼ確実に話を聞きにいきます。最低限「VPN以外からのXFRM」と「unshare直後のsetuid execve」の2本だけでも、Fragnesia系の試行は炙り出せます。

パッチ適用後の事後検証——page cache の汚染が残っていないか

もう1つ重要な論点です。パッチを当てて再起動すればカーネルは直りますが、攻撃成立後にパッチを当てた場合、page cache に汚染が残ったままだと、リブート前の su が改ざんされたバイナリのまま実行される可能性があります。検知側の論点でもあります。

事後検証の流れは3ステップ。AlmaLinux 9で実際に試しました。

# ステップ1: page cache をフラッシュして読み直し
sudo sync
sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'

# ステップ2: setuid バイナリのRPM整合性確認
sudo rpm -V coreutils sudo polkit | grep -E '^\.\.5|^S\.5|^missing'
# 5（MD5不一致）が出たら page cache 経由ではなくディスク上の改ざん。要隔離

# ステップ3: AIDEベースラインと比較
sudo aide --check 2>&1 | grep -E 'changed|added|removed' | head

AIDE のベースラインが Dirty Frag 騒動の前から取ってある組織は強い。ない組織はいまから取り直すしかありません。echo 3 > /proc/sys/vm/drop_caches は本番でI/O負荷が一瞬跳ねるので、深夜帯のメンテナンス窓で流すのが定石です。お客さま環境で昼間にやって監視アラートが鳴った例があります。

今週中に決める3つのことと、検知の網を残す意味

RHEL系運用者がFragnesiaに対して今週中に決めるべきことは3つ。Dirty Frag のときと同じ表を引っ張り出して、もう一度カラムを足しました。

判断項目選択肢判断軸
パッチ適用順外部公開エッジ → 開発サーバー → 内部基盤非特権ユーザーがログイン可能なサーバーから優先（一般ユーザー操作可能＝LPEリスク直撃）
緩和策（モジュール無効化）入れる ／ 入れないIPsec ESP・AFS／rxrpcの利用棚卸し結果しだい。使っていなければ即入れて良い
auditd／Falco 検知ルールauditd 4本 ＋ Falco 2本を最低限投入Fragnesia以降のローカル権限昇格系を継続検知する基盤として使い回せる

auditd 4本（unshare／setns／clone3／setuid execve）と Falco 2本（XFRM/AF_ALGソケット／unshare＋setuid execve）は、Fragnesia 単体のためだけでなく今後の Dirty Frag ファミリー全般に効きます。今回入れたシグネチャは次のLPE脆弱性が出ても残せます。これがいちばん大事な「検知の資産」。

Fragnesia から学び直したのは「パッチ運用のレーンと、検知のレーンを混ぜない」というシンプルな原則です。パッチは最後の解ですが、適用まで数日かかるサーバーは必ず残ります。そのあいだに「攻撃の所作の組み合わせ」を auditd と Falco で拾い続けられるか、Dirty Frag と Fragnesia で2回続けて問われました。Fragnesia は決定論的だから検知が難しい——だからこそ攻撃成立点ではなく「準備行動」を残します。AlmaLinux 公式の緩和策がそのまま RHEL／Rocky／CentOS Stream で使えたのは大きな救いでした。RHEL 純正のerrataを待つあいだ、AlmaLinux の更新タイミングと公式ブログをまず見にいく運用ルートは今後も使えます。

PR / RHEL系運用＋検知の両輪で読み直したい本

RHEL系の業務レベル運用と、auditd ログをコマンドラインで掴む実装力を両輪で押さえる2冊。Fragnesia のような決定論的LPEの「検知の網」を bash と Falco YAML で組み上げるときに、判断軸を提供してくれます。

参考情報

パッチを当てるレーンと、検知の網を張るレーン。両方を「自分の手」で回せる運用、組み立てられていますか？

auditd の rules.d、Falco のYAMLルール、AIDE のベースライン、page cache のドロップ手順——どれも単発で覚えるのではなく、現場で繰り返し手を動かして初めて身につきます。
ネットの切れ端の情報をコピペするだけでなく、現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル（図解60P）』を完全無料でプレゼントしています。

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

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

関連記事

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

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

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

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

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

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

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

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

この記事を書いた人

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

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

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

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