Um recipiente desprivilegiado pode bloquear todos os outros recipientes de começar no mesmo hospedeiro colocando um arquivo criado `/etc/ld.so.cache` no seu sistema de arquivos. Quando o Inspektor Gadget liga qualquer gadget baseado em uprobe, ele analisa este arquivo no caminho de inicialização do container. Um cache malicioso causa ~ 53 segundos de gravação da CPU, durante os quais o Docker não pode iniciar qualquer outro recipiente. Não são necessárias capacidades especiais. A avaliar — Impacto da disponibilidade, sem impacto da confidencialidade ou integridade. Todas as versões do Inspektor Gadget que suportam gadgets baseados em uprobe (trace_malloc, trace_open, trace_ssl, trace_grpc, etc.).
Quando o Inspektor Gadget liga gadgets baseados em uprobe aos contêineres, ele resolve caminhos de bibliotecas analisando o arquivo `/etc/ld.so.cache` do contêiner (`pkg/uprobetracer/ldcache_parser.go`). Este arquivo é totalmente controlado pelo recipiente. O analisador tem três vulnerabilidades. 1. ** Construção de cordas Quadráticas** (`pkg/uprobetracer/bytes.go: 36 - 44 `: A função `readStringFromBytes` concatena um byte por vez (`res += string(data[i])`), que é O(n2) em Go devido à imutabilidade de string. Com um 16 Arquivo de cache MB contendo regiões grandes sem terminadores nulos, isso causa uma CPU e um churn de memória maciços. 2 ** Validação insuficiente da contagem de entradas** (`pkg/uprobetracer/ldcache_parser.go: 120 `: O campo `EntryCount` é lido diretamente a partir do arquivo não confiável. Enquanto uma verificação dos limites por entrada impede o acesso fora de limites, o loop ainda itera até `(fileSize - headerSize) / entrySize ї 700,000 ` vezes, chamando `readStringFromBytes` em cada iteração.
3. **Overflow inteiro na detecção de formato** (`pkg/uprobetracer/ldcache_parser.go: 174 `: O ` cache 1 Computação de Len` usa uint 32 aritmética (`ldCache 1 Tamanho + cache 1. Entrar na Conta*ldCache 1 Tamanho de entrada`). Com um 'EntryCount' criado, este excede e produz um pequeno valor, fazendo com que o analisador identifique mal o formato de cache. Combinado, estas causam ~ 53 segundos de queima da CPU por anexo do recipiente quando um criado 16 O MB `/etc/ld.so.cache` está presente. - **Container runningtime DoS**: IG usa fanotificar ganchos (`pkg/container- hook`) para pausar o início do container até que o anexo uprobe termine. Enquanto o IG está bloqueado no processamento do cache malicioso, esta pausa é realizada, e o Docker serializa o recipiente começa — significando que nenhum outro recipiente pode começar no hospedeiro até o IG terminar. Isto causa efetivamente uma negação de serviço em todo o tempo de execução do container, não apenas no próprio IG. - **Atraso de inicialização do container**: Quando qualquer gadget baseado em uprobe está a funcionar (trace_malloc, trace_ssl, etc.), iniciar um container com um ld.so.cache criado atrasa o início por ~ 1 minuto. - **Monitorização da degradação**: o demon IG está bloqueado ao processar o cache malicioso, potencialmente faltando eventos de outros contentores. - **Ampliação**: Múltiplos contentores com caches criados podem ser iniciados simultaneamente para amplificar o efeito. - **Nenhum privilégio especial requerido**: Qualquer contentor pode incluir um defeito criado `/etc/ld. so.cache` na sua imagem, montar um via um volume, ou sobrescrevê- lo no tempo de execução antes de o IG iniciar um gadget de uprobe. Neste último caso, o IG inspeciona todos os recipientes já em funcionamento quando o gadget começa — isto ainda queima a CPU, mas não bloqueia o início de outros recipientes (uma vez que a pausa fanotificada só se aplica ao início de novos recipientes).
Análise de Causa Raiz. Em `pkg/uprobetracer/ldcache_parser.go`, a função `readCacheFormat 2 ` é chamado com o conteúdo completo do arquivo: ```` vai para i:= uint 32 ( 0 ); i < ldCache.EntryCount; i++ { entradaOffset:= ldEntriesOffset + i*ldCache 2 Tamanho de entrada se você for umido 32 (len( data)) <= entradaOffset+ldCache 2 Tamanho de entrada { retorno nulo // limites verificação para iteração } //... lê entrada... chave:= lerStringFromBytes(dados, teclaOffset) // O(n2) por valor da chamada:= lerStringFromBytes(dados, valorOffset) // O(n2) por chamada } ```.
A verificação dos limites por entrada evita corretamente o acesso fora de limites, mas: - O loop itera ~ 700 K vezes (limitada pelo tamanho do arquivo, não o EntryCount) - Cada chamada `readStringFromBytes` usa concatenação de cadeia quadrática Em `pkg/uprobetracer/bytes.go`. ````go func lerStringFromBytes(data []byte, startPos uint 32 ) string { res:= "" para i:= startPos; i < uint 32 (len(data)); i++ { se os dados[i] == 0 { return res } res += string(data[i]) // O(n2) — aloca uma nova string a cada iteração } retorna "" } ```.
Nota sobre as verificações de ligações de corte. O código também executa acessos de fatias sem cheques de limites apropriadas (por exemplo, `data[:len(cache) 2 Cabeçalho)]` quando ` dados` podem ser menores do que 20 bytes, e `ldCacheFile[:len(cache 1 Cabeçalho)]` quando o arquivo pode ser mais curto do que 11 bytes). Na prática, um container malicioso ** não pode atualmente desencadear um pânico** a partir destes cheques faltando. Isto é porque o `io.ReadAll` do Go (usado para ler o arquivo) sempre retorna fatias com ` cap >= 512 ` devido à sua alocação inicial de buffer (`make([]byte, 0, 512 )` na biblioteca padrão do Go). Em Go, `s[:n]` só entra em pânico quando `n > cap(s)`, não quando `n > len(s)`. Desde os dois comprimentos de cabeçalho ( 11 e 20 ) estão bem abaixo 512, as expressões de fatias são bem-sucedidas — elas simplesmente leem zero bytes além de `len`, que não correspondem a qualquer magia válida do cabeçalho.
No entanto, isso depende de um detalhe de implementação ** não documentado** do `io. ReadAll ' que poderia mudar nas futuras versões de Go. Os limites de verificação ainda são necessários para a correção e defesa em profundidade. Registro de aconselhamento: GHSA- vjhx- 2 cqw- 3 q 6 q. Identificadores relacionados: CVE- 2026 - 53941.
Tempo: GitHub Advisory Database publicou este registro em 2026 - 08 - 19 T 19: 16: 35.000 Z e lista a sua última modificação como 2026 - 08 - 19 T 19: 16: 35.000 Z. Gravidade: MODERAR. Dados de pontuação publicados: CVSS_V 4: CVSS: 4.0 /AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/África do Sul:N.
Software afetado e informações de versão: Vá o pacote github.com/inspektor-gadget/inspektor-gadget — ECOSYSTEM: introduzido 0.27.0, corrigido 0.53.1. Classificação e evidência: identificadores de fraqueza CWE- 400, CWE- 770. O registro contém 3 suporte de referências nestes tipos: WEB, PACKAGE.