<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>OSS on mimoexのブログ</title>
    <link>https://www.mimoex.net/tags/oss/</link>
    <description>Recent content in OSS on mimoexのブログ</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>ja</language>
    <lastBuildDate>Thu, 29 Oct 2026 21:25:00 +0900</lastBuildDate><atom:link href="https://www.mimoex.net/tags/oss/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>macOSでVeraCrypt使用後にカーネルパニックする問題を調べて修正したら、いつの間にか脆弱性も対処していた</title>
      <link>https://www.mimoex.net/261029-veracrypt-macos-fuset-kernel-panic-cve-2026-108982/</link>
      <pubDate>Thu, 29 Oct 2026 21:25:00 +0900</pubDate>
      
      <guid>https://www.mimoex.net/261029-veracrypt-macos-fuset-kernel-panic-cve-2026-108982/</guid>
      <description>macOSのVeraCrypt FUSE-T版で、dismount後も補助サービスが残る不具合を調査して修正PRを送ったところ、CVE-2026-108982の修正として取り込まれた。</description>
      <content:encoded><![CDATA[<p>macOSでVeraCryptを使ったあと、ボリュームをアンマウントしたはずなのに外付けSSDを取り外せず、そのままスリープさせると復帰時にカーネルパニックすることがありました。</p>
<p>最初は自分のMacで起きる不具合を直したかっただけです。
原因を追ってVeraCryptに修正プルリクを送ったところ、2026年9月25日にマージされました。
その後、同じ問題が<strong>CVE-2026-108982（CVSS v4.0: 7.2 / High）</strong> として公開され、プルリクがGitHub Security Advisoryにクレジットされました。</p>
<p>さらに、<strong>2026年10月24日に公開されたVeraCrypt 1.26.30に修正が収録</strong>されました。</p>
<p>
  <a href="/260805-macos-26-veracrypt-unmount-kernel-panic">8月頃にVeraCryptがカーネルパニックする的な記事を書きました</a>
が、
この記事では、カーネルパニックの調査から始まった修正が、なぜ暗号化ソフトウェアの脆弱性対応になったのかを振り返ります。</p>
<blockquote>
<p><strong>注意：</strong> CVEとして確認されているのは、dismount後も復号済みボリュームへアクセスできる問題です。カーネルパニックとの因果関係や、その再発防止まで公式に確認されたわけではありません。両者は分けて説明します。</p></blockquote>
<h2 id="発端dismountしたのにssdを取り外せない">発端：dismountしたのにSSDを取り外せない</h2>
<p>検証に使った環境は、Apple M4搭載のMacBook Air、macOS 26.6.2、VeraCrypt 1.26.29のFUSE-T版、FUSE-T 1.2.7です。外付けSSD上の暗号化ボリュームを使っていました。</p>
<p>VeraCryptのGUIでdismountすると、ボリューム一覧からは消えます。しかしmacOS側ではデバイスが使用中のように扱われ、正常にejectできないことがありました。さらに、この状態からスリープ・復帰すると、次のようなログを伴うカーネルパニックが発生しました。</p>
<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-text" data-lang="text"><span class="line"><span class="cl">busy timeout[1], (60s): &#39;IOMediaBSDClient&#39;
</span></span></code></pre></div><p>何かがデバイスを保持したままなのではないかと考え、<code>ps</code>、<code>mount</code>、<code>hdiutil</code>、<code>lsof</code>などでdismount前後の状態を比較しました。</p>
<p>そこで見つかったのが、<strong>dismount後もVeraCryptの補助プロセスとFUSE-Tの<code>go-nfsv4</code>が残っている</strong>という挙動です。</p>
<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-text" data-lang="text"><span class="line"><span class="cl">VeraCryptでボリュームをdismount
</span></span><span class="line"><span class="cl">    ↓
</span></span><span class="line"><span class="cl">GUI上ではボリュームが消える
</span></span><span class="line"><span class="cl">    ↓
</span></span><span class="line"><span class="cl">補助のSMBマウントとvolume.dmgは切り離される
</span></span><span class="line"><span class="cl">    ↓
</span></span><span class="line"><span class="cl">しかしVeraCryptのFUSEサービスとgo-nfsv4が生存
</span></span><span class="line"><span class="cl">    ↓
</span></span><span class="line"><span class="cl">raw deviceを保持し続ける場合がある
</span></span></code></pre></div><p>私が確認した環境では、残存した関連プロセスがなくなるとデバイスを取り外せるようになり、調査中に見られたスリープ復帰時のカーネルパニックも再現しなくなりました。ただし、これは観測上の関連であり、カーネルパニックの原因を完全に証明したものではありません。</p>
<h2 id="fuse-tのサービスが残ることはセキュリティ上も問題だった">FUSE-Tのサービスが残ることは、セキュリティ上も問題だった</h2>
<p>VeraCryptのmacOS版にはmacFUSE版とFUSE-T版があります。今回の問題は <strong>1.26.29のFUSE-T版</strong> で確認されたもので、
  <a href="https://github.com/veracrypt/VeraCrypt/security/advisories/GHSA-f3px-f8h2-fm4c" target="_blank" rel="nofollow noopener noreferrer">公式アドバイザリ</a>
ではmacFUSE版は影響を受けないとされています。</p>
<p>FUSE-T版は内部で補助ファイルシステムを使い、<code>go-nfsv4</code>とループバックSMBを介して復号済みの<code>volume.dmg</code>を扱います。ここで<code>umount</code>が成功しても、対応するFUSEサービスまで確実に終了するとは限らない状態になっていました。</p>
<p>問題は、<strong>VeraCryptがdismount済みと表示した後でも、残存サービスを通じて復号済みデータに再アクセスできる</strong>ことです。</p>
<p>実際、macOS標準のプレビューの「最近使った項目」から以前のファイルを開き直すと、パスフレーズの再入力なしに復号済みデータにアクセスできてしまいました。（これはissueやPR、公式アドバイザリでも周知の事実ですので、昨今話題の未公開の脆弱性を広める云々には該当しないと考えています）</p>
<p>これは私が最初に発見した問題ではありません。2026年6月16日に
  <a href="https://github.com/veracrypt/VeraCrypt/issues/1779" target="_blank" rel="nofollow noopener noreferrer">GitHub Issue #1779</a>
で最初の公開報告があり、6月22日には
  <a href="https://sourceforge.net/p/veracrypt/discussion/general/thread/57f938df8b/" target="_blank" rel="nofollow noopener noreferrer">SourceForgeでStephan Weisgerber氏による独立報告</a>
がありました。
後者では、dismount後も<code>go-nfsv4</code>などが残り、最近使ったファイルを開くとアクセスが復活する様子がプロセス一覧とともに記録されています。</p>
<p>私が取り組んだのは、この問題を<strong>コード上で修正し、修正前後の挙動を検証すること</strong>でした。</p>
<h2 id="pr-1866で実装した修正">PR #1866で実装した修正</h2>
<p>調査を踏まえて、
  <a href="https://github.com/veracrypt/VeraCrypt/pull/1866" target="_blank" rel="nofollow noopener noreferrer">Pull Request #1866</a>
「macOS/FUSE-T: Terminate auxiliary FUSE service on dismount」を作成しました。</p>
<p>修正の基本方針は、単に<code>umount</code>を実行するのではなく、<strong>対象となるFUSEサービスに明示的にshutdownを要求し、終了を確認してから後片付けを進める</strong>というものです。</p>
<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-text" data-lang="text"><span class="line"><span class="cl">Dismount開始
</span></span><span class="line"><span class="cl">    ↓
</span></span><span class="line"><span class="cl">対象サービスのPID・SerialInstanceNumber・SlotNumberを取得
</span></span><span class="line"><span class="cl">    ↓
</span></span><span class="line"><span class="cl">対象ボリュームに対応するサービスか照合
</span></span><span class="line"><span class="cl">    ↓
</span></span><span class="line"><span class="cl">補助FUSEファイルシステム経由でshutdown要求
</span></span><span class="line"><span class="cl">    ↓
</span></span><span class="line"><span class="cl">fuse_exit() / fuse_unmount()
</span></span><span class="line"><span class="cl">    ↓
</span></span><span class="line"><span class="cl">対応するサービスプロセスの終了を待機
</span></span><span class="line"><span class="cl">    ↓
</span></span><span class="line"><span class="cl">補助マウントポイントを削除
</span></span></code></pre></div><p>PIDだけで終了対象を決めるのではなく、シリアル番号とスロット番号も照合するようにしました。また、shutdown要求への応答が返る前にFUSEの通信路を閉じないよう、終了処理を別スレッドで実行する構成にしました。</p>
<p>PRでは、公式1.26.29と修正ビルドを同じコンテナ、同じFUSE-TのSMBバックエンドで比較しました。</p>
<table>
  <thead>
      <tr>
          <th>確認項目</th>
          <th>VeraCrypt 1.26.29</th>
          <th>PR #1866の修正ビルド</th>
      </tr>
  </thead>
  <tbody>
      <tr>
          <td>GUIからのdismount</td>
          <td>完了と表示</td>
          <td>完了と表示</td>
      </tr>
      <tr>
          <td>補助SMBマウント</td>
          <td>消える</td>
          <td>消える</td>
      </tr>
      <tr>
          <td><code>volume.dmg</code></td>
          <td>detachされる</td>
          <td>detachされる</td>
      </tr>
      <tr>
          <td>対象のVeraCrypt補助プロセス</td>
          <td>残存</td>
          <td>終了</td>
      </tr>
      <tr>
          <td>対応する<code>go-nfsv4</code></td>
          <td>残存</td>
          <td>終了</td>
      </tr>
  </tbody>
</table>
<p>特に重要だったのは、<strong>SMBバックエンドそのものを削除しなくても、サービスを適切に終了させれば問題のアクセス経路を閉じられた</strong>ことです。これは後に公開されたSecurity Advisoryにも記載されています。</p>
<h2 id="マージ後さらに大規模なhardeningが行われた">マージ後、さらに大規模なhardeningが行われた</h2>
<p>PRは2026年8月31日に作成し、<strong>9月25日にmaintainerのMounir Idrassi氏によってマージ</strong>されました。</p>
<p>レビューでは、SMBを有効にしたまま修正を検証した点が評価され、明示的なshutdownと終了待ちという方針が支持されました。</p>
<p>ただし、私の最初のパッチがそのまま完成形になったわけではありません。9月26〜29日にかけて、maintainerがサービス終了処理の競合状態、ファイルディスクリプタの引き継ぎ、mountやprocessの識別、異常終了時のcleanup、補助マウントディレクトリの保護などを追加でhardeningしました。</p>
<p>つまり、<strong>#1866でサービスを明示的に終了する仕組みを導入し、後続コミットで本番利用に向けた安全性と例外処理が大きく強化された</strong>という経緯です。</p>
<h2 id="cve-2026-108982の公開とsecurity-advisory">CVE-2026-108982の公開とSecurity Advisory</h2>
<p>この問題は10月12日にMITREから<strong>CVE-2026-108982</strong>として公開されました。分類は <strong>CWE-459（Incomplete Cleanup）</strong>、CVSS v4.0の基本スコアは <strong>7.2（High）</strong> です。</p>
<p>10月14日には、maintainerによる
  <a href="https://github.com/veracrypt/VeraCrypt/security/advisories/GHSA-f3px-f8h2-fm4c" target="_blank" rel="nofollow noopener noreferrer">GitHub Security Advisory（GHSA-f3px-f8h2-fm4c）</a>
が公開されました。</p>
<p>自分は最初の発見者ではありませんが、個人的に気になったことを試してissueに報告してプルリクを作ったらクレジットされました。</p>
<p>このCVEは
  <a href="https://nvd.nist.gov/vuln/detail/CVE-2026-108982" target="_blank" rel="nofollow noopener noreferrer">NISTのNVD</a>
にも収録され、修正PR #1866が参照されています。個人の不具合調査から始まった変更が、脆弱性管理の仕組みを通じて広く追跡されることになりました。</p>
<h2 id="そしてveracrypt-12630で正式リリース">そしてVeraCrypt 1.26.30で正式リリース</h2>
<p><strong>2026年10月24日、
  <a href="https://github.com/veracrypt/VeraCrypt/releases/tag/VeraCrypt_1.26.30" target="_blank" rel="nofollow noopener noreferrer">VeraCrypt 1.26.30</a>
が正式に公開されました。</strong></p>
<p>
  <a href="https://github.com/veracrypt/VeraCrypt/releases/tag/VeraCrypt_1.26.30" target="_blank" rel="nofollow noopener noreferrer">リリースノート</a>
では、macOS向けのセキュリティ修正としてCVE-2026-108982とGHSA-f3px-f8h2-fm4cが明示されています。FUSE-Tのcleanupを修正し、補助マウントを保護するとともに、サービス終了を確認できない場合にはエラーを報告する内容です。</p>
<h3 id="12629から更新する場合の注意">1.26.29から更新する場合の注意</h3>
<p>ここはFUSE-T版を利用している方に重要です。</p>
<p><strong>公式リリースノートは、1.26.29から更新する際、すべてのボリュームをdismountしてmacOSを再起動してから更新後のビルドを使用するよう案内しています。</strong></p>
<p>アプリを1.26.30に上書きしても、1.26.29から既に生き残っている補助サービスが自動的に終了するわけではないためです。以前Issueで議論されていた<code>pkill</code>等による手動のprocess killも、対象を取りこぼしたり、使用中のサービスを誤って終了して書き込みを中断したりするおそれがあり、確実な回避策とはされていません。</p>
<p>なお、この記事の執筆時点（2026年10月29日）では、GitHub Security Advisoryの<code>Patched versions</code>欄にまだ<code>None</code>と表示されていますが、<strong>1.26.30への修正収録は公式リリースノートで明示されています</strong>。</p>
<h2 id="振り返って">振り返って</h2>
<p>今回の経緯を一行にまとめると、こうなります。</p>
<ul>
<li>外付けSSDをejectできない／スリープ復帰でkernel panic</li>
<li>残存するFUSE-Tサービスを調査</li>
<li>
  <a href="https://github.com/veracrypt/VeraCrypt/issues/1845" target="_blank" rel="nofollow noopener noreferrer">#1845</a>
で同じような症状の方を発見、リプ送る</li>
<li>shutdown修正をPR #1866として実装・検証</li>
<li>2026/09/25 upstream merge</li>
<li>maintainerによる追加hardening</li>
<li>2026/10/12 CVE-2026-108982公開</li>
<li>2026/10/14 GHSA公開・修正者としてcredit</li>
<li>2026/10/24 VeraCrypt 1.26.30に修正収録</li>
</ul>
<p>最初は自分のMacで起きた困りごとを直すための調査でした。それが、実際に暗号化ソフトウェアのセキュリティ問題を修正する仕事につながりました。</p>
<p>暗号化ソフトウェアの安全性は、AESのような暗号アルゴリズムだけで決まるわけではありません。今回のように、<strong>「dismountした」という操作に対応して、復号済みデータへのアクセス権とサービスの寿命を本当に終了できるか</strong>も重要です。</p>
<p>また、OSSでは発見者、分析者、修正実装者、maintainerがそれぞれ異なる役割を持ちます。自分はその中で修正の実装と検証を担当し、upstreamへのマージと正式リリースまで確認できました。個人的にも印象に残る経験でした。</p>
<h2 id="参考リンク">参考リンク</h2>
<ul>
<li>
  <a href="https://github.com/veracrypt/VeraCrypt/releases/tag/VeraCrypt_1.26.30" target="_blank" rel="nofollow noopener noreferrer">VeraCrypt 1.26.30 — 正式リリースとリリースノート</a>
</li>
<li>
  <a href="https://github.com/veracrypt/VeraCrypt/pull/1866" target="_blank" rel="nofollow noopener noreferrer">PR #1866 — macOS/FUSE-T: Terminate auxiliary FUSE service on dismount</a>
</li>
<li>
  <a href="https://github.com/veracrypt/VeraCrypt/security/advisories/GHSA-f3px-f8h2-fm4c" target="_blank" rel="nofollow noopener noreferrer">GitHub Security Advisory — GHSA-f3px-f8h2-fm4c</a>
</li>
<li>
  <a href="https://www.cve.org/CVERecord?id=CVE-2026-108982" target="_blank" rel="nofollow noopener noreferrer">CVE-2026-108982（CVE.org）</a>
</li>
<li>
  <a href="https://nvd.nist.gov/vuln/detail/CVE-2026-108982" target="_blank" rel="nofollow noopener noreferrer">CVE-2026-108982（NIST NVD）</a>
</li>
<li>
  <a href="https://github.com/veracrypt/VeraCrypt/issues/1845" target="_blank" rel="nofollow noopener noreferrer">VeraCrypt Issue #1845 — FUSE-T残存プロセス等の調査</a>
</li>
<li>
  <a href="https://sourceforge.net/p/veracrypt/discussion/general/thread/57f938df8b/" target="_blank" rel="nofollow noopener noreferrer">SourceForge — Stephan Weisgerber氏による独立報告</a>
</li>
</ul>
]]></content:encoded>
    </item>
    
  </channel>
</rss>
