控制碼是表示系統資源 (例如一部分記憶體或一個檔案) 的參照。在這種情況下，程式碼無法確實釋放控制碼，因為在沒有對應項目的情況下不安全地呼叫了危險方法。

大部分的 Unreleased Resource 問題都會導致一般軟體可靠性問題。但如果攻擊者蓄意觸發資源洩漏，就可以藉由耗盡資源集區的方式來試圖發動 Denial of Service。

範例 1：以下程式碼會建立 SafeEvpPKeyHandle 的新執行個體，但呼叫 DangerousAddRef 方法而沒有使用 DangerousRelease 的對應呼叫。

var pkey = NativeMethods.ENGINE_LOAD_SSL_PRIVATE_KEY(...);
var safeEvpHandle = new SafeEvpPKeyHandle(handle: handle, ownsHandle: true);
bool success = false;

try {
    safeEvpHandle.DangerousAddRef(ref success);
    var handle = safeEvpHandle.DangerousGetHandle();
} catch (ObjectDisposedException ex) { 
    //...
} finally {
    safeEvpHandle.close();
}

範例 2：以下程式碼會建立 SafeEvpPKeyHandle 的新執行個體，但呼叫 DangerousRelease 方法而沒有使用 DangerousAddRef 的對應呼叫。

var pkey = NativeMethods.ENGINE_LOAD_SSL_PRIVATE_KEY(...);
var safeEvpHandle = new SafeEvpPKeyHandle(handle: handle, ownsHandle: true);
bool success = false;

try {
    var handle = safeEvpHandle.DangerousGetHandle();
} catch (ObjectDisposedException ex) { 
    //...
} finally {
    safeEvpHandle.DangerousRelease();
    safeEvpHandle.close();
}

控制碼是表示系統資源 (例如一部分記憶體或一個檔案) 的參照。在這種情況下，程式碼不會將目前物件設定為底層控制碼的擁有者，因此無法在處理物件後確實釋放控制碼。

大部分的 Unreleased Resource 問題都會導致一般軟體可靠性問題。但如果攻擊者蓄意觸發資源洩漏，就可以藉由耗盡資源集區的方式來試圖發動 Denial of Service。

範例 1：以下程式碼會建立 SafeEvpPKeyHandle 的新執行個體，但無法透過將 ownsHandle 參數設為 false 來確實讓物件釋放控制碼。

var pkey = NativeMethods.ENGINE_LOAD_SSL_PRIVATE_KEY(...);

var safeEvpHandle = new SafeEvpPKeyHandle(handle: handle, ownsHandle: false);

if (safeEvpHandle.IsInvalid) {
	...
}
safeEvpHandle.close();

控制碼是表示系統資源 (例如一部分記憶體或一個檔案) 的參照。在這種情況下，程式碼無法透過使用已失效的控制碼來可靠地釋放該控制碼。

大部分的 Unreleased Resource 問題都會導致一般軟體可靠性問題。但如果攻擊者蓄意觸發資源洩漏，就可以藉由耗盡資源集區的方式來試圖發動 Denial of Service。

範例 1：以下程式碼會建立 SafeEvpPKeyHandle 的新執行個體，但在透過 SetHandleAsInvalid 使控制碼失效後呼叫 DangerousGetHandle，這可能會傳回過時的控制碼值。

var pkey = NativeMethods.ENGINE_LOAD_SSL_PRIVATE_KEY(...);
var safeEvpHandle = new SafeEvpPKeyHandle(handle: handle, ownsHandle: true);
...
safeEvpHandle.SetHandleAsInvalid();
...
var handle = safeEvpHandle.DangerousGetHandle();
...
safeEvpHandle.close();

程式可能會無法釋放 LDAP 資源。

資源洩漏至少有兩種常見原因：

- 錯誤條件以及其他異常情況。

- 不確定程式的哪一部份負責釋放資源。

大部分的 Unreleased Resource 問題都會導致一般軟體可靠性問題，但是如果攻擊者蓄意觸發資源洩漏的話，攻擊者就可能會藉由耗盡資源集區的方式來發動 Denial of Service 攻擊。

範例 1：在正常情況下，以下程式碼會執行 LDAP 查詢，處理 Active Directory 傳回的結果，並關閉配置的 DirectoryEntry 物件。但是，如果在執行 LDAP 查詢或處理結果時發生異常，將不會關閉 DirectoryEntry 物件。這會導致應用程式發生記憶體洩漏，因為 DirectoryEntry 會在內部使用 COM API 查詢 Active Directory 伺服器。

  ...
  DirectoryEntry entry = new DirectoryEntry("LDAP://CN=users,DC=fabrikam,DC=com");
  DirectorySearcher mySearcher = new DirectorySearcher(entry);
  SearchResultCollection result = mySearcher.FindAll();
  CheckUsers(result);
  mySearcher.Dispose();
  entry.Close();
  ...

程式可能會無法釋出通訊端。


資源洩漏至少有兩種常見原因：

- 錯誤條件以及其他異常情況。

- 不確定程式的哪一部份負責釋放資源。

大部分的 Unreleased Resource 問題都會導致一般軟體可靠性問題，但是如果攻擊者蓄意觸發資源洩漏的話，攻擊者就可能會藉由耗盡資源集區的方式來發動 Denial of Service 攻擊。

範例 1：下列方法絕對不會關閉它所開啟的通訊端。因此，在繁忙的環境中，這可能會導致 JVM 用盡它所有的通訊端。

private void echoSocket(String host, int port) throws UnknownHostException, SocketException, IOException
{
  Socket sock = new Socket(host, port);
  BufferedReader reader = new BufferedReader(new InputStreamReader(sock.getInputStream()));

  while ((String socketData = reader.readLine()) != null) {
    System.out.println(socketData);
  }
}

範例 2：在正常條件下，以下修正會適當地關閉通訊端以及任何相關的串流。但是，如果對螢幕讀取或寫入資料時發生異常，通訊端物件就不會關閉。如果經常發生此狀況，系統就會耗盡所有通訊端，並且無法處理任何其他連線。

private void echoSocket(String host, int port) throws UnknownHostException, SocketException, IOException
{
  Socket sock = new Socket(host, port);
  BufferedReader reader = new BufferedReader(new InputStreamReader(sock.getInputStream()));

  while ((String socketData = reader.readLine()) != null) {
    System.out.println(socketData);
  }
  sock.close();
}

程式可能會無法釋出系統資源。

資源洩漏至少有兩種常見原因：

- 錯誤條件以及其他異常情況。

- 不確定程式的哪一部份負責釋放資源。

大部分的 Unreleased Resource 問題都會導致一般軟體可靠性問題，但是如果攻擊者蓄意觸發資源洩漏的話，攻擊者就可能會藉由耗盡資源集區的方式來發動 Denial of Service 攻擊。

範例 1：下列方法絕對不會關閉它所開啟的檔案控制碼。用於 FileInputStream 的 finalize() 方法最終會呼叫 close()，但是並不保證在叫用 finalize() 方法前會經過多少時間。因此，在繁忙的環境中，這可能會導致 JVM 用盡它所有的檔案控制碼。

private void processFile(String fName) throws FileNotFoundException, IOException {
  FileInputStream fis = new FileInputStream(fName);
  int sz;
  byte[] byteArray = new byte[BLOCK_SIZE];
  while ((sz = fis.read(byteArray)) != -1) {
    processBytes(byteArray, sz);
  }
}

程式可能會無法釋出系統資源。

資源洩漏至少有兩種常見原因：

- 錯誤條件以及其他異常情況。

- 不確定程式的哪一部份負責釋放資源。

大部分的 Unreleased Resource 問題都會導致一般軟體可靠性問題，但是如果攻擊者蓄意觸發資源洩漏的話，攻擊者就可能會藉由耗盡資源集區的方式來發動 Denial of Service。

範例 1：下列程式碼在 performOperationInCriticalSection() 之前建立鎖定，但如果該方法拋出異常，就無法釋放該鎖定。

ReentrantLock  myLock = new ReentrantLock ();

myLock.lock();
performOperationInCriticalSection();
myLock.unlock();

該程式無法正確處置使用未管理系統資源的受管物件。
造成無法正確處置使用未管理系統資源的受管物件有兩種常見原因：

- 錯誤條件以及其他異常情況。
- 不確定程式的哪一部份負責釋放資源。

一小部分的受管.NET 物件子集使用未受管系統資源。.NET 的記憶體回收器可能無法以預期方法釋放原始受管物件。因此，記憶體回收器無法察覺未受管資源所消耗的記憶體，應用程式可用的記憶體就可能不足。大部分的未受管資源洩漏問題都會導致一般軟體可靠性問題，但是如果攻擊者蓄意觸發未受管資源洩漏，攻擊者就可能會藉由耗盡未受管資源集區的方式來發動 Denial of Service 攻擊。

範例 1：下列方式會從內送串流 incomingStream 建立受管 Bitmap 物件。Bitmap 會被控制並持續傳出串流 outgoingStream。決不會明確呼叫 incomingBitmap 與 outgoingBitmap 的 Dispose() 方法。

正常來說，您可以放心的倚賴記憶體回收器在安全的時間，為不使用未受管系統資源的受管物件進行此作業。記憶體回收器會在適合的時間呼叫 Bitmap.Dispose()。但是，該 Bitmap 物件使用稀少、未受管的系統資源。記憶體回收器可能無法在耗盡未受管資源集區之前呼叫 Dispose()。

private void processBitmap(Stream incomingStream, Stream outgoingStream, int thumbnailSize)
{
	Bitmap incomingBitmap = (Bitmap)System.Drawing.Image.FromStream(incomingStream);

	bool validBitmap = validateBitmap(incomingBitmap);
	if (!validBitmap)
		throw new ValidationException(incomingBitmap);

	Bitmap outgoingBitmap = new Bitmap(incomingBitmap, new Size(thumbnailSize, thumbnailSize));
	outgoingBitmap.Save(outgoingStream, ImageFormat.Bmp);
}

當程式繼續使用已釋放的指標時，就會產生 Use after free 錯誤。就像 double free 錯誤和記憶體洩露錯誤一樣，use after free 錯誤有以下兩種情況，有時這兩張情況會同時發生：

- 錯誤條件以及其他異常情況。

- 對於程式中負責釋放記憶體的部分混淆了。

Use after free 錯誤有時對程式來說是沒有任何影響的，但有時它會造成程式當機。目前，在技術上對釋放的記憶體空間進行重新分配是可行的，並且已被攻擊者所利用，發動了 Buffer overflow 攻擊，而我們對此類的攻擊不會有任何的察覺。

範例 1：以下程式碼舉例說明了 use after free 錯誤：

char* ptr = (char*)malloc (SIZE);
...
if (err) {
    abrt = 1;
    free(ptr);
}
...
if (abrt) {
    logError("operation aborted before commit", ptr);
}