Linux Kernelの脆弱性(ssh-keygen-pwn: Important: CVE-2026-46333)

05/16/2026にLinux Kernelの脆弱性(ssh-keygen-pwn: Important: CVE-2026-46333)が公開されました。今回はこちらの脆弱性の概要と、各ディストリビューションの対応について纏めます。

[過去関連リンク(最新5件)]

一次情報源

CVSS/プライオリティ

  • CVE-2026-46333
  • Priority/CVSS SCORE
    • NVD(CVSSv4): Not disclosed
    • NVD(CVSSv31): Not disclosed
    • Red Hat(CVSSv4): Not disclosed
    • Red Hat(CVSSv31): 7.8 : Important
  • CVSS Vector
    • NVD(CVSSv4): Not disclosed
    • NVD(CVSSv31): Not disclosed
    • Red Hat(CVSSv4): Not disclosed
    • Red Hat(CVSSv31): CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
  • EPSS Score/Percentile
    • DATE(JST): 2026-05-16
    • EPSS: 0.000160000
    • Percentile: 0.038860000

修正方法

各ディストリビューションの情報を確認してください。

概要(詳細は一次情報源をご確認ください)

Linusの投稿(Qualysにより指摘されたptraceの問題)

Linusによるptraceの問題とパッチを纏めた投稿はこちらになります。

この情報によると、今回の問題はtaskの”dumpability”から来ています。taskの”dumpability(dumpableか否か)”は、基本的にtaskのメモリイメージ（コンセプトとしてはコアダンプできるか否か）から来ており、mmに関連付けられていない場合には意味がありません。

殆ど全ての場合、この機能を使用するのはtaskがmmポインタを持っている場合です。しかし、特別なケースとして__ptrace_may_access()はMMと関係なく独立して様々なものをチェックしています（通常はPTRACE_MODE_READ_FSCREDSなどのフラグを明示的に使用します）。これにはVMが無くなった（あるいはこれまでVMが無かった）threadも含みます。

言い換えると、MM ポインタがない場合は、スレッドが MM を持っていたことがあるかどうかキャッシュされた「最終のdumpable」フラグを使用 (カーネル スレッドの場合は設定されないためゼロ)します。

ここでコードを見てみましょう。

元々のコードで削除されたものは、下記になります。

一方、修正後には、ここのロジックのところは下記の関数に置き換えられます

注意深く見てみると、以前のコードでは

  • mmが割り当てられていて
  • get_dumpable(mm) != SUID_DUMP_USERであり
  • ptrace_has_cap()が否定（つまり、ptraceがケーパビリティを持っていない時）

に、EPERM(権限不足)としてエラーで返していました。つまり、mmがNULLになった場合には、EPERMではなく「security_ptrace_access_check(task, mode);」をreturnとして返してしまっていました。

一方で、Linus氏が纏めている通り、MMポインタがない場合、スレッドがMMを持っていたことがあるかどうかキャッシュされた「最終ダンプ可能性」フラグを使用しますが、カーネルスレッドの場合は設定されないためゼロになります。つまり、__ptrace_may_access()が許可されます。ここが根本的な原因です。

今回の問題ですが、__ptrace_may_access()がチェックをスキップして許可になってしまっています。この問題の応用ですが、do_exit() の実行中、カーネルは exit_files() の前に exit_mm() を実行するため、特権プロセスが mm をドロップした後もファイルディスクリプタを開いたままになっている時間があります。同じuidで実行されている非特権プロセスが、この時間中に pidfd_getfd(2) を呼び出すことで、終了するプロセスが開いているファイルディスクリプタを奪い取ることができます。

このファイルディスクリプタが、例えば特権を持ったバイナリが特権をドロップする前に開いたroot所有のファイル (たとえば、permanently_set_uid() の前に ssh-keysignによって開かれたSSH ホストキーや、setreuid() の前にchageによって開かれた/etc/shadow) を指している場合、攻撃者はそれらのファイルへのハンドルを取得できます。

PoC

GitHubで既にPoCが公開されています。

緩和策

Qualysの提案としての緩和策は、下記になります。

sudo sysctl -w kernel.yama.ptrace_scope=3
echo 'kernel.yama.ptrace_scope = 3' | sudo tee /etc/sysctl.d/99-ssh-keysign-pwn.conf

ただしこれは、「ptrace全部を使えなくしてしまえ！」という、割と乱暴な緩和策です。これによりptraceが使えなくなるため、gdbやstraceも使えなくなります。あくまでもこの緩和策は「一時的」なものであり、根本的には各ディストリビューションが用意してくれる、修正済みのLinux Kernelを使う必要があります。

主なディストリビューションの対応方法

詳細は、各ディストリビューションの提供元にご確認ください

対処方法

各ディストリビューションの案内に従い、アップデートを行ってください。

[参考]

タイトルとURLをコピーしました