A Linux Standard Base Specification 2.0.1 para libc impõe restrições nos argumentos para algumas funções internas [1]. Se essas restrições não forem atendidas, o comportamento das funções não será definido.


O valor 1 sempre deve ser transmitido ao primeiro parâmetro (o número de versão) da seguinte função do sistema de arquivos:

	__xmknod

O valor 2 sempre deve ser transmitido ao terceiro parâmetro (o argumento de grupo) das seguintes funções de cadeia de caracteres largos:

__wcstod_internal
__wcstof_internal
_wcstol_internal
__wcstold_internal
__wcstoul_internal

O valor 3 sempre deve ser transmitido como o primeiro parâmetro (o número de versão) das seguintes funções do sistema de arquivos:

__xstat
__lxstat
__fxstat
__xstat64
__lxstat64
__fxstat64

Excluir um ponteiro gerenciado fará com que o programa trave ou execute ações impróprias quando, mais tarde, o código de gerenciamento de ponteiro supor que o ponteiro ainda é válido. O exemplo a seguir ilustra o erro.

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

A única exceção a essa regra é quando uma classe de ponteiro gerenciado oferece suporte a uma operação de "separação", permitindo que o programador assuma o controle de gerenciamento da memória para o ponteiro especificado. Se o programa desconectar o ponteiro da classe de gerenciamento antes de chamar delete, essa classe não saberá mais usar o ponteiro.

No .Net, variáveis estáticas são inicializadas com os respectivos valores padrão. No entanto, o uso dessas variáveis sem a inicialização pode levar a problemas baseados na lógica de negócios ou pode ser usado para a execução de um ataque de Negação de Serviço (DoS). Programas nunca devem usar o valor padrão uma variável.

Não é incomum os programadores usarem uma variável não inicializada no código que trata erros ou outras circunstâncias raras e excepcionais. Avisos de variáveis não inicializadas algumas vezes podem indicar a presença de um erro tipográfico no código.

Exemplo 1: O código a seguir será compilado pelo compilador .Net sem qualquer erro. No entanto, a instrução int a = (Int32)i + (Int32)j; a seguir lança uma exceção sem tratamento e trava o aplicativo em tempo de execução.

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

A maioria dos problemas de variáveis não inicializadas resulta em problemas gerais de confiabilidade de software, mas, se os invasores puderem provocar intencionalmente o uso de uma variável não inicializada, talvez eles consigam lançar um ataque de negação de serviço fazendo com que o programa trave.

O programa talvez não consiga liberar um recurso do sistema.

Vazamento de recursos têm pelo menos duas causas comuns:

- Condições de erro e outras circunstâncias excepcionais.

- Confusão acerca de qual parte do programa é responsável pela liberação do recurso.

A maioria dos problemas de recursos não liberados resulta em problemas gerais de confiabilidade de software. No entanto, se um invasor puder provocar intencionalmente um vazamento de recursos, talvez ele consiga lançar um ataque de negação de serviço esgotando o pool de recursos.

Exemplo 1: O método a seguir nunca fecha o identificador de arquivo que ele abre. O método Finalize() para StreamReader chama Close() eventualmente, mas não há nenhuma garantia de quanto tempo será necessário antes que o método Finalize() seja invocado. Na verdade, não há nenhuma garantia de que Finalize() nunca será invocado. Em um ambiente muito ativo, isso pode fazer com que a VM use todos os seus identificadores de arquivo disponíveis.

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

Exemplo 2: Em condições normais, o código a seguir executa uma consulta de banco de dados, processa os resultados retornados pelo banco de dados e fecha o objeto SqlConnection alocado. Porém, se ocorrer uma exceção durante a execução do SQL ou o processamento dos resultados, o objeto SqlConnection não será fechado. Se isso acontecer com frequência suficiente, o banco de dados ficará sem cursores disponíveis e não poderá executar mais consultas 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();
	...

A atividade do Android aloca uma instância Camera que não é liberada em um retorno de chamada onPause(), onStop() ou onDestroy(). O sistema operacional Android invoca esses retornos de chamada sempre que precisa enviar a atividade atual para segundo plano ou quando precisa destruir a atividade temporariamente nos casos em que o sistema está com poucos recursos. Ao não liberar o objeto Camera corretamente, a atividade impede que outros aplicativos (ou até mesmo instâncias futuras do mesmo aplicativo) acessem a câmara. Além disso, manter a posse da instância de Camera enquanto a atividade está pausada pode afetar negativamente a experiência do usuário por meio do esgotamento desnecessário da bateria.

Exemplo: O código a seguir descreve uma atividade do Android que não substitui o método onPause() base, que deve ser usado para liberar o objeto Camera, nem o libera corretamente durante sua sequência de desligamento.

public class UnreleasedCameraActivity extends Activity {
  private Camera cam;

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

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

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

A atividade do Android aloca um objeto de mídia que não é liberado em um retorno de chamada onPause(), onStop() ou onDestroy(). O sistema operacional Android invoca esses retornos de chamada sempre que precisa enviar a atividade atual para segundo plano ou quando precisa destruir a atividade temporariamente nos casos em que o sistema está com poucos recursos. Ao não liberar o objeto de mídia corretamente, a atividade faz com que acessos subsequentes ao hardware de mídia do Android (por outros aplicativos ou até mesmo pelo mesmo aplicativo) retrocedam para as implementações de software ou até mesmo falhem completamente. Deixar abertas muitas instâncias de mídia não liberadas pode fazer com que o Android lance exceções, causando efetivamente uma negação de serviço. Além disso, manter a posse da instância de mídia enquanto a atividade está pausada pode afetar negativamente a experiência do usuário por meio do esgotamento desnecessário da bateria.

Exemplo: O código a seguir descreve uma atividade do Android que não substitui o método onPause() base, que deve ser usado para liberar o objeto de mídia, nem o libera corretamente durante sua sequência de desligamento.

public class UnreleasedMediaActivity extends Activity {
  private MediaPlayer mp;

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

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

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

A atividade do Android mantém um manipulador de banco de dados SQLite do Android que não está fechado no retorno de chamada onPause(), onStop() ou onDestroy(). O sistema operacional Android invoca esses retornos de chamada sempre que precisa enviar a atividade atual para segundo plano ou quando precisa destruir a atividade temporariamente nos casos em que o sistema está com poucos recursos. Ao não fechar o banco de dados corretamente, a atividade poderá esgotar cursores disponíveis do dispositivo se for reiniciada constantemente. Além disso, dependendo da implementação, o sistema operacional Android também pode lançar DatabaseObjectNotClosedException, que travará o aplicativo se a exceção não for detectada.

Exemplo: O código a seguir descreve uma atividade do Android que armazena os dados do usuário em cache e os grava em disco quando a atividade é interrompida. Observe que isso não substitui o método onPause() base, que deve ser usado para liberar o objeto de banco de dados, nem o libera corretamente durante sua sequência de desligamento.

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