Dirty Frag CVE-2026-43284：Linux ローカル権限昇格のリスクと緩和ガイド

Dirty Frag は、2026 年 5 月に公開され、実際の悪用の兆候も報告されている Linux kernel local privilege escalation 脆弱性群である。Microsoft は、攻撃者がすでに低権限の code execution を得た後に root へ昇格する post-compromise risk として説明している。Ubuntu も CVE-2026-43284 を High として扱っている。

この種の脆弱性で危険なのは、「remote から一発で侵入される」ことではない。「侵入後に権限を一気に広げられる」ことだ。攻撃者が弱い SSH account、WebShell、container escape、低権限 service account、phishing 後の remote access などで local execution を得ると、Dirty Frag を使って root を取得し、security tooling の停止、credential の読み取り、log 改ざん、lateral movement、persistence につなげる可能性がある。

Dirty Frag に関係する CVE

現在の公開情報では、Dirty Frag は主に二つの番号と関係している。

CVE-2026-43284：Linux kernel の xfrm/ESP path に関係する。Microsoft が言及する esp4、esp6 はこのリスク領域に含まれる。
CVE-2026-43500：Microsoft は rxrpc に関連すると説明しているが、2026 年 5 月 8 日時点では NVD にまだ正式公開されておらず、patch status も変化中である。

したがって、実際の確認では一つの CVE だけを見るべきではない。esp4、esp6、rxrpc、関連する xfrm/IPsec 機能が有効か、必要か、distribution kernel patch があるかをまとめて確認するのが安全だ。

技術的な概要

Microsoft と Ubuntu の説明によると、CVE-2026-43284 は Linux kernel の networking と memory-fragment handling、特に ESP/IPsec path における shared page fragments の扱いに関係する。

簡単に言えば、data page は splice などの仕組みで network buffer に attach されることがある。その後の kernel path が、それらの fragment を privately owned data とみなして in-place modification できるものとして扱うと、本来書き込むべきでない場所で in-place decrypt や modification が起きる可能性がある。攻撃者はこれを利用して page cache behavior を操作し、最終的に local privilege escalation を達成し得る。

これは以前公開された CopyFail（CVE-2026-31431）と背景が似ている。どちらも Linux page cache、kernel data path、local privilege escalation を中心にしている。Dirty Frag が危険なのは、追加の attack path を持ち、狭い race window に依存する従来型 LPE より安定しやすい可能性がある点だ。

優先的に見るべき環境

Dirty Frag は local privilege escalation なので、攻撃者がすでに対象 machine 上で code を実行できることが前提になる。優先的に確認すべき環境は次の通り。

SSH を公開している Linux server。
WebShell を書き込まれる可能性がある Web application server。
multi-user login host、bastion、developer machine、CI/CD runner。
container host、Kubernetes node、OpenShift node。
IPsec、VPN、xfrm、RxRPC 関連機能を使う system。
Ubuntu、RHEL、CentOS Stream、AlmaLinux、Fedora、openSUSE など主要 distribution を動かす server。

local multi-user、container、露出した application path がまったくない server ではリスクは低めだ。しかし「攻撃者が low-privileged shell を得る可能性」がある system では、高優先度の kernel vulnerability として扱うべきである。

まず patch を優先する

最も確実な修正は、distribution が提供する kernel security update をインストールし、新しい kernel で reboot することだ。

Ubuntu の CVE page では、CVE-2026-43284 は 2026 年 5 月 8 日に公開され、priority は High とされている。Microsoft も Linux Kernel Organization が CVE-2026-43284 の修正を公開しており、できるだけ早く patch を適用するよう促している。

まず system を確認する。

1
2


uname -a
cat /etc/os-release

distribution に合わせて kernel を更新する。

1

sudo apt update && sudo apt full-upgrade

または：

1

sudo dnf update

更新後は、新しい kernel で起動していることを必ず確認する。

1

uname -r

kernel package をインストールしただけで reboot していない場合、古い kernel が動き続けるため、脆弱性は残る可能性がある。

暫定緩和：関連 module を無効化する

patch がまだない、または production をすぐ reboot できない場合は、関連 module を一時的に無効化できるか評価する。Ubuntu の緩和策は、esp4、esp6、rxrpc の loading を block し、すでに loaded なら unload するというものだ。

modprobe block rule を作成する。

1
2
3


echo "install esp4 /bin/false" | sudo tee /etc/modprobe.d/dirty-frag.conf
echo "install esp6 /bin/false" | sudo tee -a /etc/modprobe.d/dirty-frag.conf
echo "install rxrpc /bin/false" | sudo tee -a /etc/modprobe.d/dirty-frag.conf

early boot で module が load されないよう initramfs を更新する。

1

sudo update-initramfs -u -k all

すでに loaded な module を unload する。

1

sudo rmmod esp4 esp6 rxrpc 2>/dev/null

module がまだ loaded か確認する。

1

grep -qE '^(esp4|esp6|rxrpc) ' /proc/modules && echo "Affected modules are loaded" || echo "Affected modules are NOT loaded"

module が業務で使われている場合、unload に失敗することがある。その場合、block rule は reboot 後に有効になる可能性が高い。

無効化前に業務影響を確認する

上の緩和コマンドをそのまま貼り付けてはいけない。esp4、esp6、xfrm/IPsec 関連機能は、VPN、tunnel、encrypted networking、Kubernetes/container networking、企業 network configuration で使われている可能性がある。rxrpc も、その protocol に依存する workload に影響する。

production で実行する前に、少なくとも次を確認する。

1
2
3


lsmod | grep -E '^(esp4|esp6|rxrpc|xfrm)'
ip xfrm state
ip xfrm policy

IPsec VPN や関連 kernel networking に依存している場合、module 無効化で接続が切れる可能性がある。その場合は、module block に長く頼るより、kernel patch と maintenance reboot を早めに計画するべきだ。

侵害後確認を省かない

Microsoft は、緩和策だけでは成功した exploit による変更を元に戻せない可能性があると強調している。攻撃者がすでに root を得ていた場合、persistence、file modification、log tampering、session data access が残っている可能性がある。

少なくとも次を確認する。

1
2
3
4
5


journalctl -k --since "24 hours ago" | grep -Ei "dirty|frag|exploit|segfault|xfrm|rxrpc|esp"
last -a
lastlog
sudo find /tmp /var/tmp /dev/shm -type f -mtime -3 -ls
sudo find / -perm -4000 -type f -mtime -7 -ls 2>/dev/null

特に次を見る。

異常な su、sudo、SUID/SGID process launch。
最近追加された ELF executable。
Web directory 内の怪しい PHP、JSP、ASP file。
SSH authorized_keys の変更。
systemd service、cron、rc.local に追加された persistence。
container host 上の異常な privileged container や mount。

悪用が疑われる場合は、host を isolate し、evidence を保存し、credential を rotate してから cleanup する。module unload や cache clearing だけで安全になったと考えてはいけない。

drop_caches について

Microsoft は、一部の post-exploitation integrity verification で cache clearing を検討できると述べている。

1

echo 3 | sudo tee /proc/sys/vm/drop_caches

これは vulnerability fix でも incident cleanup command でもない。cache clearing は追加の disk I/O と production performance への影響を起こし得る。影響を理解したうえで補助操作として使うべきだ。本当の修正は patch、reboot、integrity verification、persistence check である。

推奨対応順序

production environment では、次の順序が比較的安全だ。

Linux asset と kernel version を棚卸しする。
exposed SSH、Web workload、container host、multi-user system を優先する。
reboot できる system は早急に patch して新 kernel で起動する。
まだ patch または reboot できない system は、esp4、esp6、rxrpc の無効化を評価する。
su、SUID/SGID、異常 ELF、WebShell、container escape indicator の監視を強化する。
悪用が疑われる host では侵害後確認と credential rotation を行う。

まとめ

Dirty Frag は「remote one-click」脆弱性ではないが、侵害後のリスクを大きく高める。攻撃者が local で低権限 code execution を得るだけで、CVE-2026-43284 と関連する rxrpc attack surface を使って root へ昇格できる可能性がある。

管理者にとって重要なのは PoC 研究ではない。kernel が影響を受けるかを確認し、distribution security update をインストールして reboot すること。patch window 前には関連 module の無効化を評価すること。そして露出している system や疑わしい system では integrity と persistence を確認することだ。

参考リンク：