Linux C ライブラリ用の Linux 標準ベース仕様 2.0.1 では、一部の内部関数の引数に制約を課しています [1]。この制約を満たさないと、関数の動作は未定義の状態です。
1 の値が、次の File System 関数の第 1 パラメーター (バージョン番号) に渡されている。

	__xmknod

2 の値が、次のワイド文字列関数の第 3 パラメーター (グループ引数) に渡されている。

__wcstod_internal
__wcstof_internal
_wcstol_internal
__wcstold_internal
__wcstoul_internal

3 の値が、次の File System 関数の第 1 パラメーター (バージョン番号) として渡されている。

__xstat
__lxstat
__fxstat
__xstat64
__lxstat64
__fxstat64

管理されるポインタを削除すると、ポインタ管理コードがポインタは引き続き無効であると見なした場合に、プログラムがクラッシュするなど正常ではない動きをする可次の例ではこのエラーについて示します。

  std::auto_ptr<foo> p(new foo);
  foo* rawFoo = p.get();
  delete rawFoo;

このルールの唯一の例外は、管理されるポインタクラスで「切り離す」操作が可能であり、所定のポインタのメモリをプログラマが管理できる場合です。delete のコール前にプログラムによってポインタが管理クラスから切り離されると、この管理クラスはそれ以降ポインタを使用しなくなります。

.Net では、静的変数はデフォルト値に初期化されますが、それらの変数を初期化せずに使用すると、ビジネス ロジック ベースの問題が発生するか、またはサービス拒否 (DOS) 攻撃を実行するために使用される可能性があります。プログラムでは、変数のデフォルト値を決して使用しないようにします。

プログラマがエラーまたはその他の極めて稀なケースや例外を処理するコードで Uninitialized Variable を使用するのは珍しいことではありません。Uninitialized Variable が、コード記述におけるタイプミスの警告となる場合もあります。

例 1: 次のコードは、.Net コンパイラによってエラーなしでコンパイルされます。ただし、次のステートメント int a = (Int32)i + (Int32)j; は処理対象外の例外を発生し、アプリケーションが実行時にクラッシュします。

    class Program
        {
            static int? i = j;
            static int? j;
            static void Main(string[] args)
            {
                j = 100;
                int a = (Int32)i + (Int32)j;

                Console.WriteLine(i);
                Console.WriteLine(j);
                Console.WriteLine(a);
            }
        }
    

Uninitialized Variable の問題点の大半は一般にソフトウェアの信頼性の問題を引き起こします。しかし攻撃者が意図的に Uninitialized Variable の使用を誘発することが可能な場合、攻撃者はプログラムをクラッシュさせることにより、Denial of Service 攻撃を開始することができます。

プログラムはシステムリソースの解放に失敗する可能性があります。

リソースリークには、少なくとも 2 つの一般的原因があります。

- エラー条件などの例外的状況。

- プログラムのどの部分がリソースを解放するかに関する混乱。

開放されていないリソースの問題点の大半は、一般にソフトウェアの信頼性の問題をもたらします。しかし攻撃者による意図的なリソース リークが可能な場合、攻撃者はリソース プールを枯渇させることにより、Denial of Service 攻撃を開始する可能性があります。

例 1: 次のメソッドは、開いたファイル ハンドルを閉じていません。StreamReader の Finalize() メソッドは最終的に Close() をコールしますが、Finalize() メソッドが呼び出されるまでの所要時間には何も保証がありません。それどころか、Finalize() が呼び出されるという保証すらありません。その結果、処理量が多い環境では、利用可能なファイルハンドラを VM が使い尽くしてしまう可能性があります。

private void processFile(string fName) {
	StreamWriter sw = new StreamWriter(fName);
	string line;
	while ((line = sr.ReadLine()) != null)
		processLine(line);
}

例 2: 通常の条件下では、次のコードはデータベース クエリを実行し、データベースから戻された結果を処理し、割り当てられた SqlConnection オブジェクトを閉じます。しかし、SQL の実行中や結果の処理中に例外が発生すると、SqlConnection オブジェクトは閉じられないままになります。これが頻繁に発生する場合、データベースは利用できるカーソルが不足し、SQL クエリをそれ以上実行できなくなります。

        ...
	SqlConnection conn = new SqlConnection(connString);
	SqlCommand cmd = new SqlCommand(queryString);
	cmd.Connection = conn;
	conn.Open();
	SqlDataReader rdr = cmd.ExecuteReader();
	HarvestResults(rdr);
	conn.Connection.Close();
	...

Android アクティビティは、onPause()、onStop()、または onDestroy() コールバックで解放されていない Camera インスタンスを割り当てます。 Android OS は、現在のアクティビティをバックグラウンドに送信する必要がある場合や、システムリソースの不足時に現在のアクティビティを一時的に破壊する必要がある場合に、これらのコールバックを呼び出します。 Camera オブジェクトを適切に解放しないため、アクティビティが原因で他のアプリケーション (または同じアプリケーションの将来のインスタンス) はカメラにアクセスできません。 さらに、アクティビティの一時停止中に Camera インスタンスを所有し続けた場合、電池が無駄に消費されてしまうため、ユーザー体験の質が低下することがあります。

例: 次のコードは、Camera オブジェクトを解放するために使用する必要があるベースの onPause() メソッドを上書きもせず、シャットダウン処理中に適切に解放もしない Android アクティビティを記述しています。

public class UnreleasedCameraActivity extends Activity {
  private Camera cam;

  @Override
  public void onCreate(Bundle state) {
      ...
  }

  @Override
  public void onRestart() {
      ...
  }

  @Override
  public void onStop() {
      cam.stopPreview();
  }
}

Android アクティビティは、onPause()、onStop()、または onDestroy() コールバックで解放されていないメディアオブジェクトを割り当てます。Android OS は、現在のアクティビティをバックグラウンドに送信する必要がある場合や、システムリソースの不足時に現在のアクティビティを一時的に破壊する必要がある場合に、これらのコールバックを呼び出します。アクティビティがメディアオブジェクトを適切に解放できないと、Android のメディアハードウェアに対する (他のアプリケーションまたは同じアプリケーションによる) 後続のアクセスが、ソフトウェア実装に左右される、あるいは完全に失敗することさえあります。多数の解放されていないメディアインスタンスをオープンしたままにしておくと、Android が例外を発生させ、事実上 Denial of Service を引き起す可能性があります。さらに、アクティビティの一時停止中に media インスタンスを所有し続けた場合、電池が無駄に消費されてしまうため、ユーザー体験の質が低下することがあります。

例: 次のコードは、メディアオブジェクトを解放するために使用されるべきベースの onPause() メソッドを上書きもせず、シャットダウン処理中に適切に解放もしない Android アクティビティを記述しています。

public class UnreleasedMediaActivity extends Activity {
  private MediaPlayer mp;

  @Override
  public void onCreate(Bundle state) {
      ...
  }

  @Override
  public void onRestart() {
      ...
  }

  @Override
  public void onStop() {
      mp.stop();
  }
}

Android アクティビティは、onPause()、onStop()、または onDestroy() コールバックで閉じられていない Android SQLite データベースハンドラを割り当てます。Android OS は、現在のアクティビティをバックグラウンドに送信する必要がある場合や、システムリソースの不足時に現在のアクティビティを一時的に破壊する必要がある場合に、これらのコールバックを呼び出します。データベースを適切に閉じることができないと、アクティビティが常に再起動されている場合、使用可能なカーソルのデバイスが使い果たされてしまう可能性があります。また、実装の内容によっては、Android オペレーティングシステムもまた DatabaseObjectNotClosedException を発生させる可能性があるため、この例外が認識されない場合はアプリケーションがクラッシュします。

例: 次のコードは、停止された場合にユーザーデータをキャッシュして、そのデータをディスクに書き込む Android アクティビティを記述しています。データベースオブジェクトを解放するために使用されるベース onPause() は上書きされません。また、シャットダウンの処理中にデータベースオブジェクトを適切に解放することもしません。

public class MyDBHelper extends SQLiteOpenHelper {
  ...
}

public class UnreleasedDBActivity extends Activity {
  private myDBHelper dbHelper;
  private SQLiteDatabase db;

  @Override
  public void onCreate(Bundle state) {
      ...
      db = dbHelper.getWritableDatabase();
      ...
  }

  @Override
  public void onRestart() {
      ...
  }

  @Override
  public void onStop() {
      db.insert(cached_data);     // flush cached data
  }
}