Josef Bacik

A vulnerabilidade está relacionada ao encerramento inadequado dos temporizadores para soquetes do kernel no kernel do Linux. Quando os soquetes TCP são fechados, a função `inet csk clear xmit timers()` é chamada para interromper os temporizadores. No entanto, essa função pode ser chamada a partir de qualquer contexto, inclusive quando o bloqueio do soquete está ativo, o que pode fazer com que os temporizadores em execução sejam concluídos muito mais tarde. Para soquetes do kernel, isso pode fazer com que os netns sejam liberados antes que o temporizador seja concluído, pois os soquetes do kernel não mantêm uma referência aos netns. O patch adiciona uma nova função `inet csk clear xmit timers sync()` que usa `sk stop timer sync()` para garantir que todos os temporizadores sejam encerrados antes que o soquete do kernel seja liberado.

O problema está relacionado a uma desreferência de ponteiro NULL na função `ff layout cancel io()`, o que pode causar um panic quando `nfs4 ff layout prepare ds()` falha. O problema decorre de uma verificação inconsistente de `mirror ds`, em que o código verifica apenas `!mirror->mirror ds` em vez de `IS ERR OR NULL(mirror ds)`. Essa inconsistência pode levar a um panic quando ocorre um erro. A vulnerabilidade está relacionada ao componente NFS do kernel do Linux.

O problema está relacionado a uma vulnerabilidade de uso após liberação (use-after-free) na funcionalidade de gravação direta do Sistema de Arquivos de Rede (NFS) no kernel do Linux. Isso ocorre quando o `nfs direct request` é concluído duas vezes seguidas, levando a um subfluxo de `refcount t` e a um aviso de uso após liberação. A origem desse problema é o caminho de conclusão das solicitações de commit, onde solicitações assíncronas podem ser concluídas antes que a próxima seja enviada, resultando na conclusão do `nfs direct request` duas vezes. O número estimado de dispositivos potencialmente afetados em todo o mundo não foi especificado. Não há informações sobre incidentes reais em que esse problema tenha sido explorado. Os detalhes técnicos sobre a exploração incluem: - A função vulnerável é `nfs direct write schedule work()`. - O problema decorre da conclusão repetida do `nfs direct request`. - A função `nfs commit end()` está envolvida no caminho de conclusão das solicitações de commit. - As chamadas `get dreq()` e `put dreq()` são utilizadas em torno do processamento de eventos e dos caminhos de conclusão.

O problema ocorre quando o kernel Linux não consegue gravar o cache de espaço livre em uma instância e, em seguida, tenta gravá-lo novamente. Na segunda tentativa, ele chama `btrfs get extent()` no inode para obter o mapeamento de extensão, mas como se trata de um novo grupo de blocos e o inode de espaço livre sempre pesquisa a raiz de commit para evitar um impasse com a árvore, ele não encontra nada e retorna um `EXTENT MAP HOLE` para o intervalo solicitado. Isso ocorre porque, na primeira vez que o kernel tenta gravar o cache de espaço, ele encontra um erro e descarta o mapeamento de extensão, o que é normal para arquivos comuns, mas não para o inode do cache de espaço livre, onde se espera que o mapa de extensão esteja sempre correto. Como resultado, na segunda tentativa, o kernel acaba com um mapa de extensão incorreto.

O problema está relacionado ao componente btrfs do kernel do Linux e envolve um erro no tratamento da consulta à árvore de blocos na função `btrfs relocate sys chunks()`. Esse erro pode levar à corrupção de dados e, potencialmente, permitir que um invasor provoque uma negação de serviço. A vulnerabilidade é causada por duas condições impossíveis: a chave de pesquisa ser configurada para procurar um item da árvore de blocos com um deslocamento de -1 e a chave encontrada corresponder a um item de bloco após uma pesquisa bem-sucedida. O deslocamento é decrementado em 1 antes do próximo ciclo, tornando impossível encontrar um item de bloco devido a restrições de alinhamento e tamanho.

Uma vulnerabilidade de deadlock foi resolvida no kernel do Linux, especificamente no sistema de arquivos btrfs. O problema ocorre quando os mecanismos de bloqueio do fiemap e do extent interagem, podendo causar um deadlock. Isso acontece porque o bloqueio do extent é mantido para todo o intervalo durante a operação do fiemap, o que pode levar a uma situação em que ocorre uma falha de página enquanto o bloqueio ainda está ativo, resultando em um deadlock. A vulnerabilidade existe no código normal, mas não havia sido percebida anteriormente devido à falta de anotações lockdep. Para corrigir isso, o patch simplesmente não mantém o bloqueio de extensão durante toda a duração do fiemap, o que é seguro porque o código mantém o controle de sua posição na árvore.

O problema ocorre devido a uma lógica de interrupção incorreta na função `btrfs replace file extents`. Testes de injeção de erros revelaram um caso em que poderia ocorrer um sistema de arquivos corrompido com uma extensão faltando no meio de um arquivo. O problema surge porque a instrução `if` para decidir se um abortamento é necessário está incorreta. A única situação em que um abortamento ocorreria é se um código de erro específico (`-EOPNOTSUPP`) não fosse retornado e a chamada viesse do código de clonagem de arquivos. No entanto, o código de pré-alocação também usa esse caminho e, em vez disso, um abortamento deveria ocorrer se houvesse um erro, exceto para o erro `-EOPNOTSUPP` quando proveniente do código de clonagem de arquivos.

O problema ocorre no sistema de arquivos btrfs quando uma operação `rename exchange` falha ao inserir a segunda referência de inode, resultando em uma referência de inode pendente e em potencial corrupção do sistema de arquivos. Isso ocorre porque a referência de inode de um lado da renomeação é inserida primeiro e, se a inserção da segunda referência de inode falhar, a primeira fica pendente. O problema foi descoberto por meio de testes de estresse com injeção de erros. A correção envolve abortar a operação se a inserção da primeira referência de inode for bem-sucedida.

Foi corrigida uma vulnerabilidade no kernel Linux, especificamente no sistema de arquivos btrfs. O problema ocorria quando testes de injeção de erros causavam um panic devido a um código de operação inválido. O fluxo de erros desse código lida com os erros de maneira adequada e, em vez de entrar em panic, deveria simplesmente retornar o erro. Essa vulnerabilidade foi identificada durante testes de injeção de erros e está relacionada à função `link to fixup dir` no arquivo `fs/btrfs/tree-log.c`.