原文

Linuxカーネルにおいて、以下の脆弱性が解決されました。KVMでは、VMが終了中にvCPUが存在しない場合でもメモリがダーティになった際にWARNしないよう改善しました。メモリをダーティとしてマークする際には、VMがまだ生存中（すなわちrefcountがゼロでない）場合に限り、稼働中またはロード済みのvCPUがないことに対して警告を出します。これにより、x86 SEV-ESゲストのメモリリークを修正でき、実質的に誤検知（false positive）となっていたWARNを回避できます。 一部のSEV-ES VM-Exitでは、KVMはユーザースペースへのexitをまたいでゲストページの書き込み可能なマッピングを保持し、通常は次のKVM_RUN時にページをアンマップします。しかし、ユーザースペースがそのexit後にKVM_RUNを呼び出さない場合、vCPUが破棄される際にページのアンマップを行う必要があり、それが稼働中のvCPUがないことに関するWARNを引き起こします。 または、nested_vmx_free_vcpu()内で行われているように（全く無関係な理由によるものですが）、WARNを抑制するために一時的にvCPUをロードする方法もあります。しかし、破棄中にvCPUをロードするのは望ましくありません（理想的にはnVMXコードを整理すべきです）。また、SEV-ESコードを複雑化させるリスクがあり（KVMはvCPUが既にロードされていない場合のみ一時的なload()+put()を実行する必要があります）、最終的には無意味です。 WARNが生じる動機は、KVMが対応するGFNをアクティブなvCPUのダーティリングにプッシュせずにゲストメモリをダーティにすることを防ぐためであり、例えばユーザースペースがダーティページを見逃さないようにする目的があります。しかし、VMのrefcountがゼロになるためには、ダーティリングのユーザースペースマッピングが一切存在しない必要があります。これはダーティリングのマッピングがvCPU FDに対するmmap()を伴うためです。つまり、ユーザースペースがダーティリングの有効なマッピングを持っている限り、そのvCPUファイルおよび所有するVMはまだ生存していることになります。したがって、ユーザースペースがダーティリングに到達できないため、KVMが技術的にダーティリングへのプッシュを「見逃す」かどうかは無関係です。