NVIDIA GPUのECCを破る「GPUThor」──研究は8月25日に公開済み、攻撃コードは11月15日

トロント大学の研究チーム（Chris S. Lin、Joyce Qu、Aditya Rajeev、Gururaj Saileshwar）が、NVIDIA GPUのECC（誤り訂正符号）保護をすり抜けるRowhammer攻撃「GPUThor」を、ACM SIGSAC Conference on Computer and Communications Security（CCS '26、2026年11月15〜19日・オランダ、ハーグ）で発表する。研究の存在と概要はすでに公開済みだ。NVIDIAへの通報は2026年4月29日、NVIDIAの要請による機密保持は8月25日に解除され、その日にNVIDIAがセキュリティ通知を公開している。残っているのは攻撃コードの公開で、研究チームのGitHubリポジトリ（github.com/sith-lab/gputhor）は「11月15日公開」とアナウンスされており、この記事を書いている8月27日にcurlで開くとまだ404だった。

• トロント大学がNVIDIAのECC保護を破るRowhammer攻撃「GPUThor」を発表。確認された対象はRTX A4000/A4500/A5000/A6000の4機種（いずれもAmpere世代・GDDR6）
• NVIDIAへの通報は4月29日、機密保持は8月25日に解除。攻撃コードの公開は11月15日（ACM CCS 2026の会期）で、確認時点でGitHubはまだ404
• 研究チームの主張では、ECC有効のRTX A6000で2時間に1回のGPUリセットが発生し、root権限奪取までの所要時間もGPUHammer比で21.9時間→1.1分に短縮したとしている

いつ何が起きて、読者は何をすればいいか

「GPUThor」はCCS 2026の会期（11月15〜19日）に合わせて話題になると見込まれる研究だが、実際の情報公開は二段階に分かれている。

• すでに起きたこと（8月25日）: NVIDIAへの内々の開示が4月29日、NVIDIAの要請による機密保持が8月25日に解除され、同日NVIDIAがセキュリティ通知を出した。GPUThorの紹介サイトと論文PDFもこの時点で一般公開されている。つまり「何が起きるか」の中身自体は、本記事の時点（8月27日）ですでに読める。
• これから起きること（11月15日）: 攻撃を再現できる実装コード（github.com/sith-lab/gputhor）の公開はCCS 2026の会期初日、11月15日に予定されている。本記事の確認時点でこのリポジトリはまだ404で、コードは存在しない。

読者がやるべきことは、11月15日より前に「自分の使っている・貸しているGPUが対象4機種に該当するか」「NVIDIAの通知に沿った対応が済んでいるか」を確認しておくことだ。攻撃の再現手順やコードの中身は本記事では扱わない。

背景:GPUのRowhammerは「ECCで防げる」とされていた

Rowhammerは、あるDRAMの行を高速に繰り返しアクセスすると、隣接する行のビットが意図せず反転してしまうという、DRAMそのものの物理的な弱点だ。同じ研究グループは2025年、USENIX Security 2025で「GPUHammer」を発表し、NVIDIA A6000のGDDR6メモリでRowhammerによるビット反転を初めて実証した。このときのPoC（概念実証）では、単一のビット反転でDNNモデルの精度を80%から0.1%まで落とせることを示している（gpuhammer.com）。

NVIDIAはこの2025年の通知（gpuhammer.comの記載によれば2025年7月付）で、ECCの有効化を対策として推奨していた。翌2026年には同グループがIEEE S&P 2026（Oakland 2026）で「GPUBreach」を発表し、GPUのページテーブルを破壊することでroot権限奪取に到達できることを示したが、これもECC有効時は防げるとされていた領域だった。

GPUThorはこの「ECCがあれば防げる」という前提を崩す、という主張の研究だ。gputhor.comの説明によれば、GPUのメモリリクエストの結合処理（coalescing）と、TRR（Target Row Refresh、DRAMに内蔵されたRowhammer対策）が発動するタイミングという、いずれも未公開の内部挙動を分析し、標的行への負荷のかけ方を工夫したという。これにより、単純な繰り返しでは埋もれてしまうはずの負荷を集中させ、ECCが訂正できる範囲を超えるビット反転を発生させた、としている。攻撃の再現手順やコードの詳細には、本記事では立ち入らない。

対象GPUは4機種、いずれもAmpere世代のワークステーション向け

研究チームがビット反転を確認したのは、GDDR6メモリを積むAmpere世代のワークステーション向けGPU4機種のみだ。一部だけを挙げるのではなく、gputhor.comの「Affected GPUs」表にある全モデルを載せる。

（24時間×バンク4本の計測値、ECC無効時。出典はいずれもgputhor.com本文の表とFAQ）

比較対象のGPUHammerは16 flips/GB、先行する別の攻撃「GDDRHammer」は758 flips/GB（GPUHammer比47倍）にとどまっていた。CPU側の代表的な攻撃であるBlacksmith（DDR4）が約550,000 flips/GBとされており、GPUThorのA5000での値（377,000）はこの水準に近づいている、というのがサイト側の位置づけだ。

NVIDIAのAI向けGPUは国内でもRubin GPU 2万7500基規模の国家AIインフラのように急速に展開が進んでおり、NVIDIAは依然としてAIチップ市場でシェア首位を維持している。今回対象になった4機種はいずれも2020年前後に発売されたAmpere世代のワークステーション向けカードで、最新のBlackwell世代とは別世代である点は押さえておきたい。

対象外・未確認のGPU

サイトのFAQでは、A100/H100（サーバー向け、HBM）や、Blackwell世代のRTX 5090/RTX 6000（GDDR7）が名指しで問われている。回答は「HBM・GDDR6X・GDDR7では、現行の攻撃パターンではビット反転が発生しなかった」というものだ。ただし「別のパターンでビット反転を起こせる可能性は否定できない」とも明記されており、"未検証で安全"と"検証済みで安全"は別物として扱われている。HBM3やGDDR7はオンダイECCを追加で備えるが、これはエラーの可視性を下げる方向に働くもので、ビット反転そのものを防ぐわけではない、という注記も付いている。

ECCの前提はどう変わったか

サイトのFAQ「I already enabled ECC on my GPU. Am I safe?」への回答は「No」だ。対象4機種のSECDED方式ECCは、16バイト単位で1ビットの訂正・2ビットの検出までしか対応しない。GPUThorはこの単位内で387件の2ビットエラー（検出はされるが訂正できない）と、2件の3ビットエラー（ECCが誤って"訂正"してしまい、気づかれないまま値が化ける）を発生させたとしている。

実害として挙げられているのは次の2つだ。

• DoS（サービス拒否）とRMA化: ECC有効のRTX A6000で、2時間に1回のペースでGPUリセットが発生し、実行中のジョブがすべて落ちる。1日経過すると、行の再割り当てができなくなったGPU自身が「要交換（RMA-ready）」と自己申告する状態になったという。
• root権限奪取: GPUのページテーブルを破壊する手口（GPUBreachと同系統）を、ECC有効な環境でも成立させたとしている。特権のないCUDAプログラムから、ホストCPU側のrootシェルまで到達する。

1回あたりの攻撃時間も短縮されていると主張されており、A6000でのroot権限奪取までの所要時間は、GPUHammerのパターンでは21.9時間かかっていたのに対し、GPUThorのパターンでは1.1分だったとしている。

このように「1台の物理GPUを複数の利用者で時分割共有する」運用では影響が大きい。GPUをレンタルする契約自体は珍しくなく、たとえばGoogleはSpaceXのデータセンターからGPU約11万基規模の計算資源を借りている。GPUThorが想定するリスクは、こうした「借りて使う」構造そのものに刺さる。

ベンダの案内はあるか

NVIDIAは8月25日、gputhor.comが「security notice」として案内しているページ（nvidia.custhelp.com/app/answers/detail/a_id/5873）を公開している。ただし本記事はこのページ自体に自動アクセスできなかった（後述）ため、内容はgputhor.com側の要約に依っている。

研究チーム自身がFAQ「What should I do right now?」で挙げている当面の対応は次の3点だ。

1. クラウド事業者は、単一の物理GPUを信頼できないテナント間で共有しない
2. NVIDIAのエラー訂正カウンタを監視する（急増は攻撃の兆候になりうる）
3. すべてのGPU利用者は、信頼できないコードをGPU上で実行する際に注意を払う

チーム自身も「完全な対策には将来のGPUでのハードウェアレベルの防御が必要」としており、既存GPUへの完全な後付け対策があるという主張はしていない。長期的な対策として、複数ビットを訂正できるChipkill級のECCへの移行（GDDR6のSECDEDで既に使っている記憶帯域・容量6.25%をさらに消費する）、DDR5で提案されているRFM（Refresh Management）やPRAC（Per-Row Activation Counting）といったハードウェア対策も挙げられている。

11月15日までに確認しておくこと

GPUを借りて使う側、貸す側それぞれで、コード公開前に確認しておく価値があるのは次の点だ。

• 使っている（貸している）GPUが、RTX A4000/A4500/A5000/A6000のいずれかに該当するか
• ECCが有効になっているか、有効ならエラー訂正カウンタを監視できる状態か
• 単一の物理GPUを複数の信頼できないテナントで共有する運用になっていないか
• NVIDIAのセキュリティ通知（a_id/5873）に記載の対応が、自社の運用に反映されているか

これらはいずれも、攻撃コードが公開される11月15日より前に確認できる項目だ。

実際にHTMLソースを開いて気づいたこと

gputhor.comのページ本文には出てこないが、ページのHTMLソースをそのまま開くと、サイト運営者向けと見られるコメントが消し忘れの形で残っていた。「25 Aug 2026より前にこのサイトを一般公開しないこと」「NVIDIAへの開示は2026年4月29日、8月25日までの機密保持で合意しており、その日にNVIDIAがセキュリティ通知を出す予定」「コード・アーティファクトのリポジトリは11月15日まで非公開」という内容で、本文の「Responsible disclosure」節に書かれている内容と一致していた。curlで生のHTMLを取得しなければ気づかない箇所だが、内容自体は本文の記述と食い違っていない。

数字の食い違いと、確認できなかったこと

• ページ冒頭のリード文は「500×–23,500× more bit flips」という丸めた表現を使っている一方、個別GPUごとの表・FAQでは「4,548倍〜23,597倍」「7,155倍〜23,597倍」という数字が使われており、下限の"500倍"がどのGPU・条件に対応するのか、ページ内の記載だけでは特定できなかった。本記事では個別GPUの表にある数字を優先して使っている。
• NVIDIAのセキュリティ通知本体（nvidia.custhelp.com/app/answers/detail/a_id/5873、および2025年分のa_id/5671）は、curlでのアクセスが403（Technical Difficulties）で返ってきて自動取得できなかった。通知の内容は、gputhor.com側が「with guidance」とまとめている範囲でしか確認できていない。
• GPUThorの論文PDF本体（CCS26_GPUThor.pdf）は存在を確認した（HTTP 200）が、本記事は主にgputhor.comの要約ページの記載にもとづいており、PDF本文を通読した上での検証ではない。
• 日本語圏でこの件を扱った記事があるかをZenn・QiitaのAPI経由で検索したが、「GPUThor」「GPUHammer」のいずれも該当記事は0件だった（2026年8月27日時点）。一般的なRowhammer解説記事はQiitaに1件（2018年）見つかったが、GPU向けの内容ではない。