マネージ コードで IntPtr を使用すると セキュリティおよび信頼性の問題が生じる可能性があります IntPtr のすべての使用状況を確認し SafeHandle (または類似する技術) の利用その場所に必要かどうかを決定する必要があります ...

マネージ コードで IntPtr を使用すると、セキュリティおよび信頼性の問題が生じる可能性があります。IntPtr のすべての使用状況を確認し、SafeHandle (または類似する技術) の利用その場所に必要かどうかを決定する必要があります。IntPtr が、マネージ コードの所有しうるネイティブ リソース (メモリ、ファイル ハンドル、ソケット等) を表している場合に、問題が生じる可能性があります。たとえば、マネージ コードはリソースを解放することを予期されており、それが行われない場合にはリソース リークが発生します。そのようなシナリオでは、IntPtr および IntPtr によって表されているリソースをリリースする方法に対するマルチスレッド アクセスが許可されている場合、セキュリティおよび信頼性の問題が発生する可能性があります。これらの問題は、リソースの解放時に IntPtr を再利用しようとした際に、そのリソースが他のスレッドから同時に利用されている状況では、不適切なリソースに関連付けられているデータの読み込みや書き込みが他のスレッドから可能にしてしまうような競合条件の発生も伴います。たとえば、OS ハンドルを IntPtr 型として格納し、ユーザーに Close とそのハンドルを使用している他のメソッドの同時に呼び出すことを一切の同期手続きなしに行うことを許可した場合、そのコードには、データの破損およびセキュリティの脆弱性の原因となりうるハンドルの再利用問題が含まれることになります。SafeHandle (およびその兄弟クラス CriticalHandle) は、そのようなスレッド問題を回避できるように、ネイティブ ハンドルをリソースへカプセル化する機構を提供します。(ネイティブ メソッドへの呼び出しよりも、ネイティブ ハンドルのコピーを含んでいるマネージ オブジェクトの有効期間を注意深く制御する必要性などの問題も回避できます。例: GC.KeepAlive への呼び出しを削除できます。) SafeHandle (および CriticalHandle) を使用するとパフォーマンスのオーバーヘッドが発生しますが、通常、設計時に注意することでそのオーバーヘッドを軽減することができます。