要注意：CVE-2026-31431で発生する危険なコピー失敗問題について

新たな脆弱性「CVE-2026-31431」が報告されました。今回の問題は「コピー処理の失敗（Copy Fail）」に関連しており、システム運用の現場に影響を及ぼす可能性があります。早急な確認と対策を推奨します。

これすごいな。ページにはRHEL 14.3で動作するって書いてあるけど、そんなバージョン存在しないぞ。現在のRHELは10.x系だし、ターディス（ドクター・フーのタイムマシン）でも使って未来から来たのかよ。

開示プロセスの途中で何らかの混乱があったみたいだね。ベンダー側がこの脆弱性を深刻に扱っていなくて、多くのディストリビューションでパッチが当たっていない状態のままだ。

https://access.redhat.com/security/cve/cve-2026-31431 「中程度の深刻度」「修正は延期」

https://security-tracker.debian.org/tracker/CVE-2026-31431

https://ubuntu.com/security/CVE-2026-31431

https://www.suse.com/security/cve/CVE-2026-31431.html

提案されている緩和策（modprobeの設定でカーネルモジュールalgif_aeadを無効化する）を試したいけど、ルートシェルを奪うための難読化されたシェルコード全体を実行するのはちょっと、という人のために、モジュールがロードできるかチェックするだけの読みやすいコードを置いておくよ。

python3 -c 'import socket; s = socket.socket(socket.AF_ALG, socket.SOCK_SEQPACKET, 0); s.bind(("aead","authencesn(hmac(sha256),cbc(aes))")); print("algif_aead probably successfully loaded, mitigation not effective; remove again with: rmmod algif_aead")'

同じように、緩和策が有効なら

modprobe algif_aead

でエラーが出るはずだ。

LPE = ローカル特権昇格（Local Privilege Escalation）のことね。

略語が多すぎるよ。文脈から推測するのは難しくなかったけど、使う前にちゃんと定義してほしいもんだ。

影響を受けるOS上で、自律型AIエージェントを一般ユーザー権限で動かすなんていうおバカな真似をする人がいないことを祈るよ。ゼロデイのプロンプトインジェクション攻撃とか食らったら大惨事だぞ。

RHEL 9/10だとalgif_aeadがモジュールじゃなくてビルドインだからアンロードできなかった。

というわけで、次善の策としてsystemd経由でAF_ALGを無効化する方法を見つけた。公開されている全サービスにドロップイン設定が必要になる。主要なssdhとuser@をカバーするAnsibleプレイブックを置いておくね。

https://gist.github.com/m3nu/c19269ef4fd6fa53b03eb388f77464da

Linuxカーネルの暗号化コードに関わっている人間として言わせてもらうと、定期的に発生するAF_ALGの脆弱性には本当にうんざりだ。何年も前に十分なレビューなしでカーネルに追加されたAF_ALGなんて、そもそも存在するべきじゃなかった。複雑すぎる上に、特権のないユーザー空間プログラムに対して巨大な攻撃面をさらけ出している。それに、ユーザー空間にはすでに独自の暗号化コードがあるんだから、カーネル側で持つ必要性はほとんどゼロだよ。カーネルの暗号化コードは、本来カーネル内で使う（例えばdm-cryptなど）ためのものだ。

このエクスプロイトで使われている「authencesn」なんて、本来IPsecの実装詳細であって、汎用的な暗号化・復号APIとしてユーザー空間に公開されるべきじゃなかったものだ。

もしLinuxカーネルの構成管理を担当しているなら、すべてのCONFIG_CRYPTO_USER_API_* kconfigオプションを無効にすることを強く勧める。そうしておけば、今回のバグも、過去や未来のあらゆるAF_ALGバグも悪用不可能になる。もしこれで既存のユーザー空間プログラムが動かなくなったら、ユーザー空間の暗号化コードへ移行できるように手助けしてやってくれ！中にはすでに対応済みのものもあるしね。AF_ALGなんて、そもそもエクスプロイト以外でまともに使われたことなんてほとんどないんだから。

他に選択肢はないと思う。こういうユーザー空間APIは、何年も前ならまだマシだったかもしれないけど、syzbotとかLLMを使ったバグ発見が当たり前の今の世界ではもう通用しないよ。

どのカーネルバージョンが脆弱で、どれが修正済みなのかの情報が含まれていないのは残念だよね。特に今回はビルドインモジュールで、rmmodで簡単に削除できないし…。

Fedora 44、カーネル6.19.14を使っていて自分が脆弱なのか気になったから、少し調べてlinux-cve-announceメーリングリストを見つけたよ：https://lore.kernel.org/linux-cve-announce/2026042214-CVE-2026-31431-3d65@gregkh/T/#u

これによると：

・6.18.22で修正済み（コミット fafe0fa2995a...）
・6.19.12で修正済み（コミット ce42ee423e58...）
・7.0で修正済み（コミット a664bf3d603d...）

参考になれば。

122日間再起動していないユーザーがいるArch VPSで試してみた。

結果：

OSError: [Errno 97] Address family not supported by protocol

Arch LinuxのLTSカーネルにはAF_ALGが含まれていないのかな？

Pythonの依存関係は簡単に取り除けるよ。あとx86_64のペイロードもクロスプラットフォームにしたやつがこれだ：https://github.com/tgies/copy-fail-c