句柄是表示系统资源（例如一部分内存或一个文件）的引用。在这种情况下，代码无法可靠地释放句柄，因为在没有相应方法的情况下不安全地调用了危险方法。

大部分 Unreleased Resource 问题只会导致常规软件可靠性问题，但如果攻击者能够故意触发资源泄漏，该攻击者就有可能尝试通过耗尽资源池的方式发起 Denial of Service。

示例 1：以下代码创建了 SafeEvpPKeyHandle 的新实例，但是在没有相应调用 DangerousRelease 的情况下调用了 DangerousAddRef 方法。

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 的新实例，但是在没有相应调用 DangerousAddRef 的情况下调用了 DangerousRelease 方法。

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 Object。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 和 memory leak 错误一样，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);
}