OpenBSD、IPsecのメモリ破壊を修正―AES-GMACと対象機種を確認
影響するのは特定の暗号処理を使う環境です。AES-GCMと混同せず、カーネル更新と再起動後のVPN疎通まで確認します。
公式公表日：2026-10-20 / 公開： / 更新： / 最終確認：
Codingholic 編集部 · 約3分
OpenBSDは10月20日、IPsecでAES-GMACを使う場合に、遠隔からカーネルのヒープ領域を破壊される問題を修正しました。IPsecは拠点間などの通信を保護する仕組みです。8.0向けではerrata 003として、対象CPUと暗号方式を限定した告知が出ています。
AES-GCMは今回の対象外
影響するのはAES-NIを使うamd64と、暗号コプロセッサを使うocteonです。IPsecを使っているだけで全環境が対象になるわけではなく、AES-GMACという方式とハードウェアの条件を合わせて確認します。名称が似ているAES-GCMは影響しないと明記されています。
公式パッチは暗号処理のバッファ確保を修正しています。記事確認時の告知は遠隔でのヒープオーバーフローを説明していますが、具体的な侵害事例や攻撃者によるコード実行の成功までは示していません。
8.0のerrata 003を適用する
amd64などバイナリ更新に対応する環境では、syspatchを利用できます。octeonを含む、それ以外の構成では署名付きソースパッチの手順を確認します。この修正はユーザーアプリだけの更新ではなく、カーネルの変更です。
ソースパッチにはsignifyによる署名検証と、カーネルの再構築・インストール手順が付属します。8.0用パッチを別リリースへ流用せず、利用中のリリースに対応するerrataと更新方式を選んでください。
再起動後のカーネルとVPN通信を確認
以下は編集部の手順です。unameなどでOSと機種を確認し、IPsecの設定・実際の接続で選ばれた方式を調べます。設定ファイルに候補があるだけで判断せず、管理している対向機器も含めて接続条件を記録します。
保守時間と復旧手段を確保して修正を適用し、新しいカーネルで起動します。バイナリ更新ならsyspatch -lで適用履歴を確認し、VPNの再接続、拠点間の業務通信、ログの異常を点検します。更新をインストールした段階と、更新後のカーネルが動いている段階を分けて記録します。
出典と編集について
OpenBSD Project：OpenBSD、IPsecのメモリ破壊を修正 ↗OpenBSD 8.0 errata 003の署名付きパッチ ↗
出典の報告と、編集部が提案する点検・対策を分けて記載しています。本記事の点検項目は個別環境の診断結果ではありません。