Ye Bin

Nome do software vulnerável e versões afetadas: Versões do kernel Linux anteriores à 6.6.61 Descrição: O problema está relacionado a um acesso não autorizado à memória na função proto unregister do módulo Bluetooth BNEP. O problema ocorre porque a função bnep init() ignora o valor de retorno da função bnep sock init(), que libera todos os recursos. Quando o módulo bnep é removido, bnep sock cleanup() é chamado para limpar os recursos do soquete, levando a um potencial acesso não autorizado à memória. O número estimado de dispositivos potencialmente afetados em todo o mundo não está disponível. Não há informações sobre incidentes reais em que essa falha tenha sido explorada. Recomendações: Para versões do kernel Linux anteriores à 6.6.61, atualize para a versão 6.6.61 ou posterior para resolver o problema. Como solução temporária, considere modificar a função bnep exit() para retornar o valor de retorno de bnep sock init() a fim de impedir o acesso não autorizado à memória. Restrinja o acesso ao módulo BNEP vulnerável para minimizar o risco de exploração. Evite usar o módulo BNEP até que o problema seja resolvido.

**Nome do software vulnerável e versões afetadas** Kernel do Linux (versões afetadas não especificadas) **Descrição** Uma vulnerabilidade do tipo “use-after-free” foi corrigida no kernel do Linux. O problema ocorre na função `bfad im module exit()`, onde uma liberação dupla é acionada quando a função `bfad im module init()` falha. Isso pode levar a um erro de uso após liberação (slab-use-after-free) na função ` lock acquire()`. A vulnerabilidade é causada pela chamada da função `bfad im module exit()` mesmo quando `bfad im module init()` falha, resultando em uma liberação dupla da função `fc release transport()`. **Recomendações** Para resolver o problema, certifique-se de que `bfad im module exit()` não seja chamada quando `bfad im module init()` falhar. Isso pode ser feito modificando a função `bfad init()` para chamar `bfad im module exit()` apenas quando `bfad im module init()` for bem-sucedida. No momento, não há informações sobre uma versão mais recente que contenha uma correção para essa vulnerabilidade.

**Nome do software vulnerável e versões afetadas** Kernel do Linux (versões afetadas não especificadas) **Descrição** O problema ocorre quando se instala o módulo f2fs.ko e, simultaneamente, se monta o sistema de arquivos f2fs, resultando em uma referência a ponteiro nulo (null-ptr-deref) na função `f2fs submit page bio()`. Isso ocorre porque o biset do sistema de arquivos f2fs não é inicializado antes do registro de `f2fs fs type`. O problema pode ser resolvido registrando-se `f2fs fs type` no final de `init f2fs fs()` e garantindo que todos os recursos do sistema de arquivos f2fs sejam inicializados. **Recomendações** Para resolver o problema, registre `f2fs fs type` por último em `init f2fs fs()`. Certifique-se de que todos os recursos do sistema de arquivos f2fs estejam inicializados. Como solução temporária, considere desativar a função `f2fs submit page bio()` até que um patch esteja disponível. Restrinja o acesso ao módulo `f2fs` vulnerável para minimizar o risco de exploração. Evite usar o módulo `f2fs.ko` no endpoint da API afetado até que o problema seja resolvido. No momento, não há informações sobre uma versão mais recente que contenha uma correção para essa vulnerabilidade.

**Nome do software vulnerável e versões afetadas** Versões do kernel Linux anteriores à 6.6.37 **Descrição** Um possível vazamento de memória no kernel Linux foi resolvido. O problema ocorre na função `vfio intx enable()` quando `vfio irq ctx alloc()` falha, levando a um vazamento de memória da variável `name`. **Recomendações** Atualize para a versão 6.6.37 ou posterior do kernel do Linux para resolver o problema. Como solução temporária, considere restringir o acesso à função `vfio intx enable()` até que um patch esteja disponível.

**Nome do Software Vulnerável e Versões Afetadas** Versões do kernel Linux anteriores a 5.10.0+ **Descrição** Uma vulnerabilidade de use-after-free foi identificada na função `ext4 rename dir prepare` do kernel Linux. Este problema surge quando o 'rec len' da primeira entrada de diretório é 34478, resultando em uma entrada pai ilegal. O problema ocorre porque a entrada de diretório não é verificada após a leitura do bloco de diretório em `ext4 get first dir block`. O número estimado de dispositivos potencialmente afetados não é fornecido, e não há informações sobre incidentes no mundo real onde este problema foi explorado. **Recomendações** Para resolver este problema, verifique a entrada de diretório em `ext4 get first dir block` para prevenir o erro de use-after-free. Como solução temporária, considere desativar a função `ext4 rename dir prepare` até que um patch esteja disponível. No entanto, as informações fornecidas não especificam uma versão corrigida, portanto, a recomendação é atualizar para uma versão onde este problema foi resolvido, mas a versão exata não é especificada. No momento, não há informações sobre uma versão mais recente que contenha uma correção para esta vulnerabilidade.

**Nome do software vulnerável e versões afetadas** Kernel do Linux (versões afetadas não especificadas) **Descrição** O problema está relacionado a uma leitura fora dos limites na função `resp readcap16()`. Isso pode levar a uma negação de serviço. O problema surge quando o valor `alloc len` é definido como -1104926854, fazendo com que um `arr len` muito grande seja passado para `fill from dev buffer()`, mas o `arr` tem apenas 32 bytes, resultando em uma condição fora dos limites (OOB) em `sg copy buffer()`. Para resolver esse problema, recomenda-se definir `alloc len` como `u32`. **Recomendações** No momento, não há informações sobre uma versão mais recente que contenha uma correção para essa vulnerabilidade.

**Nome do software vulnerável e versões afetadas** Kernel do Linux (versões afetadas não especificadas) **Descrição** Foi corrigida uma vulnerabilidade no kernel do Linux, especificamente no sistema de arquivos ext4. O problema ocorre quando o sistema de arquivos é remontado como somente leitura, causando uma condição de corrida em que a thread kmmpd pode sair e apontar para memória liberada, o que pode ser acionado pela chamada a `ext4 stop mmpd()`. Isso foi corrigido permitindo que a thread kmmpd saia apenas quando for parada via `ext4 stop mmpd()`. **Recomendações** No momento, não há informações sobre uma versão mais recente que contenha uma correção para essa vulnerabilidade.

**Nome do software vulnerável e versões afetadas** Kernel do Linux (versões afetadas não especificadas) **Descrição** Foi corrigido um bug no sistema de arquivos ext4 do kernel do Linux, especificamente na função `ext4 es cache extent`, que é chamada pela função `ext4 split extent at`. O problema ocorre ao executar `fsstress` com falhas de E/S injetadas, resultando em um bug no kernel e um erro interno. O rastreamento de chamadas inclui funções como `ext4 es cache extent`, `ext4 cache extents`, `ext4 find extent` e `ext4 ext map blocks`. A modificação do patch baseia-se em uma sugestão de Jan Kara para corrigir adequadamente a árvore de extensões em caso de erros ENOSPC e EDQUOT, que podem ser facilmente acionados pelos usuários. **Recomendações** No momento, não há informações sobre uma versão mais recente que contenha uma correção para esta vulnerabilidade.

**Nome do software vulnerável e versões afetadas** Versões do kernel Linux anteriores ao commit 014c9caa29d3 **Descrição** O problema está relacionado ao sistema de arquivos ext4 no kernel do Linux. Antes do commit 014c9caa29d3, uma série de comandos podia provocar um panic. Os comandos incluem montar um sistema de arquivos com a opção “errors=panic” e, em seguida, remontá-lo com a opção “abort”. Após o commit, remontar com a opção “abort” não causa mais um panic. No entanto, essa alteração também introduz um novo comportamento em que uma série diferente de comandos causará um panic, o que anteriormente não acontecia. Os comandos que agora causam um panic incluem montar com “errors=panic” e, em seguida, gravar em um gatilho específico do sistema de arquivos. Essa alteração torna o comportamento do ext4 mais consistente. **Recomendações** Para resolver o problema, atualize o kernel do Linux para uma versão que inclua o commit 014c9caa29d3 ou posterior. Como solução alternativa temporária, considere evitar o uso conjunto das opções de montagem “errors=panic” e “abort” até que um patch esteja disponível. Restrinja o acesso ao gatilho do sistema de arquivos para minimizar o risco de exploração.