Linux Standard Base Specification 2.0.1 para libc establece restricciones en los argumentos de algunas funciones internas [1]. Si no se cumplen las restricciones, no se define el comportamiento de las funciones.


El valor 1 debe transferirse al primer parámetro (el número de versión) de la siguiente función del sistema de archivos:

	__xmknod

El valor 2 debe transferirse al tercer parámetro (el argumento de grupo) de las siguientes funciones de cadenas de caracteres amplias:

__wcstod_internal
__wcstof_internal
_wcstol_internal
__wcstold_internal
__wcstoul_internal

El valor 3 debe transferirse como primer parámetro (el número de versión) de las siguientes funciones del sistema de archivos:

__xstat
__lxstat
__fxstat
__xstat64
__lxstat64
__fxstat64

La eliminación de un puntero administrado provocará que el programa se bloquee o se comporte incorrectamente cuando, más adelante, el código de administración del puntero asuma que el puntero sigue siendo válido. El ejemplo siguiente ilustra el error.

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

La única excepción a esta regla aparece cuando una clase de puntero administrado es compatible con una operación "desasociar" lo que permite al programador tomar el control de la administración de la memoria para un puntero determinado. Si el programa desasocia el puntero de la clase de administración antes de llamar delete, la clase de administración sabrá que no puede seguir utilizando el puntero.

En .NET, las variables estáticas se inicializan con los valores predeterminados. Sin embargo, el uso de dichas variables sin inicializar puede causar problemas relativos a la lógica de negocio o pueden utilizarse para ejecutar un ataque de denegación de servicio (DoS). Los programas no deben utilizar nunca el valor predeterminado de una variable.

No es infrecuente que los programadores usen una variable no inicializada en el código que administre errores u otras circunstancias excepcionales o poco comunes. Los mensajes de advertencia de variables no inicializadas pueden a menudo indicar la presencia de un error tipográfico en el código.

Ejemplo 1: el compilador .NET compilará el siguiente código sin errores. Sin embargo, la siguiente instrucción int a = (Int32)i + (Int32)j; lanza una excepción no controlada y bloquea la aplicación en tiempo de ejecución.

    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);
            }
        }
    

La mayoría de las variables no inicializadas provocan problemas generales de confiabilidad del software, pero si los atacantes pueden activar de forma intencionada el uso de una variable no inicializada, es posible que puedan iniciar un ataque por denegación de servicio, lo que bloquearía el programa.

Es posible que el programa no pueda liberar un recurso del sistema.

Las pérdidas de recursos presentan dos causas habituales:

- Condiciones de error y otras circunstancias excepcionales.

- Confusión en cuanto a la parte del programa responsable de liberar el recurso.

La mayoría de los problemas de recursos no liberados provocan problemas generales de confiabilidad del software. Sin embargo, si un usuario malintencionado puede activar de forma intencionada una pérdida de recursos, es posible que este pueda iniciar un ataque de denegación de servicio agotando el conjunto de recursos.

Ejemplo 1: el siguiente método nunca cierra el identificador de archivo que abre. El método Finalize() de StreamReader con el tiempo llama a Close(), pero no hay ninguna garantía en cuanto el tiempo que pasará antes de que se llame al método Finalize(). De hecho, no hay ninguna garantía de que se llame en algún momento al método Finalize(). En un entorno muy activo, esto puede provocar que la VM utilice todos los identificadores de archivo disponibles.

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

Ejemplo 2: en condiciones normales, el siguiente código ejecuta una consulta de base de datos, procesa los resultados devueltos por la base de datos y cierra el objeto SqlConnection asignado. Sin embargo, si se produce una excepción al ejecutar el SQL o al procesar los resultados, el objeto SqlConnection no se cerrará. Si esto ocurre con bastante frecuencia, la base de datos agotará los cursores disponibles y no podrá ejecutar ninguna otra consulta 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();
	...

La actividad de Android asigna una instancia de Camera que no se ha liberado en las devoluciones de llamada onPause(), onStop() o onDestroy(). El SO Android invoca estas devoluciones de llamadas cada vez que necesita enviar la actividad actual al segundo plano o cuando necesita destruir temporalmente la actividad debido al bajo nivel de recursos del sistema. Al no liberar correctamente el objeto Camera, la actividad impide que otras aplicaciones (o incluso futuras instancias de la misma aplicación) accedan a la cámara. Además, la conservación de la posesión de la instancia Camera mientras la actividad se encuentra pausada puede afectar negativamente a la experiencia del usuario debido a un consumo innecesario de la energía de la batería.

Ejemplo: El siguiente código describe una actividad de Android que no reemplaza el método base onPause(), que debe utilizarse para liberar el objeto Camera, ni lo libera correctamente durante la secuencia de cierre.

public class UnreleasedCameraActivity extends Activity {
  private Camera cam;

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

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

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

La actividad de Android asigna un objeto multimedia que no se ha liberado en la devolución de llamada de onPause(), onStop() o onDestroy(). El SO Android invoca estas devoluciones de llamadas cada vez que necesita enviar la actividad actual al segundo plano o cuando necesita destruir temporalmente la actividad debido al bajo nivel de recursos del sistema. Al no liberar correctamente el objeto multimedia, la actividad provoca que los siguientes accesos al hardware multimedia de Android (por parte de la misma aplicación u otras) se reviertan a las implementaciones de software o incluso presenten errores de forma conjunta. Al dejar abiertas demasiadas instancias multimedia sin liberar, Android generará excepciones, lo que provocará realmente una denegación de servicio. Además, la conservación de la posesión de la instancia multimedia mientras la actividad se encuentra pausada puede afectar negativamente a la experiencia del usuario debido a un consumo innecesario de la energía de la batería.

Ejemplo: en el siguiente código se describe una actividad de Android que no reemplaza el método base onPause(), que debe utilizarse para liberar el objeto multimedia, ni lo libera correctamente durante la secuencia de cierre.

public class UnreleasedMediaActivity extends Activity {
  private MediaPlayer mp;

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

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

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

La actividad de Android conserva un controlador de base de datos SQLite de Android que no se ha cerrado en la devolución de llamada de onPause(), onStop() o onDestroy(). El SO Android invoca estas devoluciones de llamadas cada vez que necesita enviar la actividad actual al segundo plano o cuando necesita destruir temporalmente la actividad debido al bajo nivel de recursos del sistema. Al no cerrar correctamente la base de datos, la actividad puede agotar los cursores disponibles del dispositivo si la actividad se reinicia constantemente. Además, en función de la implementación, el sistema operativo Android puede generar también DatabaseObjectNotClosedException, lo que provoca que se bloquee la aplicación si no se detecta la excepción.

Ejemplo: el siguiente código describe una actividad de Android que almacena en caché los datos de usuario y escribe los datos en el disco cuando la aplicación se ha detenido. Tenga en cuenta que no reemplaza el método base onPause(), que debería usarse para liberar el objeto de base de datos, ni lo libera correctamente durante la secuencia de cierre.

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
  }
}