Guenter Roeck

**Nome do software vulnerável e versões afetadas** Versões do kernel Linux anteriores à 6.12.0 **Descrição** O problema está relacionado a uma verificação de alinhamento excessivamente rígida na função create cache(), o que pode causar um kernel panic em determinados sistemas, como o m68k, onde o alinhamento mínimo do tipo unsigned long é de 2 bytes. O erro ocorre ao tentar criar um cache slab, resultando em uma falha na alocação. O problema decorre da suposição de que um freeptr t arbitrário (basicamente um unsigned long) está sempre alinhado a 4 ou 8 bytes, o que não é seguro. A correção envolve flexibilizar a verificação para o alinhamento mínimo real do freeptr t. **Recomendações** Para resolver o problema, atualize para uma versão do kernel Linux que inclua a correção para a verificação de alinhamento excessivamente rígida em create cache(). 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 está relacionado à função `damon feed loop next input()` no kernel do Linux, que é ineficiente e suscetível a estouros de memória. Especificamente, o cálculo de `‘score goal diff bp’` pode sofrer estouro quando `‘score’` é alto, e o cálculo de `‘compensation’` também é vulnerável a estouros. O cálculo final do valor de retorno para o caso de desempenho abaixo do esperado é novamente vulnerável a estouros quando a pontuação atual está abaixo da meta. A função foi reescrita para evitar estouros e cálculos desnecessários. 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: O problema decorre da chamada incondicional à função `fec ptp save state()`, o que pode causar um pânico no kernel em plataformas que não suportam PTP, como o i.MX25 e o i.MX27. Isso ocorre porque `fec ptp init()` não é chamado nessas plataformas, resultando em membros relacionados não inicializados em `fep`. Para resolver isso, foi adicionada uma condição para impedir que `fec ptp save state()` seja chamado se o PTP não for suportado. 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** Versões do kernel Linux anteriores à 6.6.50 **Descrição** O problema está relacionado à função `pti clone pgtable()`, que fazia suposições de alinhamento sobre o endereço inicial, notadamente assumindo que ele estivesse alinhado com PMD. Essa suposição é verdadeira no x86 64, mas não no i386, levando a um mau funcionamento na condição final e resultando em um clone “curto”. O problema ocorre quando o mapeamento do usuário possui uma cópia curta do texto da entrada. Para resolver isso, deve-se usar a forma de incremento correta para `addr`, a fim de evitar suposições de alinhamento. **Recomendações** Atualize para a versão 6.6.50 ou posterior do kernel Linux para resolver o problema. Como solução temporária, considere restringir o uso da função `pti clone pgtable()` até que um patch esteja disponível.

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 corrida de spinlock na criação de threads do kernel. A troca de contexto mantém o proprietário correto do bloqueio durante a transição das tarefas “anterior” para “próxima”, contando com que as interrupções permaneçam desativadas durante toda a duração da troca. No entanto, para threads do kernel recém-criadas, o registro de status é definido como PS S em copy thread(), o que deixa o IPL em 0, e ao restaurar o registro de status da thread “próxima” em switch to() (também conhecido como resume()), as interrupções são ativadas prematuramente. Isso causa um aviso de recursão de spinlock, conforme relatado por Guenter Roeck. A corrida foi aberta no commit 533e6903bea0 (“m68k: split ret from fork(), simplify kernel thread()”). 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** O problema está relacionado ao kernel do Linux, onde o teste de unidade `iov iter` causa uma falha em sistemas nommu, como a emulação qemu kc705-nommu. O teste chama a função `vmap()` diretamente, o que não é suportado em sistemas nommu, resultando em um kernel panic. O `TEST IOV ITER` precisa depender do `MMU` para evitar essa falha. **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** O problema está relacionado a um vazamento de memória no componente de handshake do kernel do Linux. O teste `handshake req destroy test1` passou a falhar depois que `sock release(sock)` foi substituído por `fput(filp)` para corrigir o vazamento de memória. A função `fput(filp)` geralmente atrasa o fechamento final e a limpeza, o que não tem consequências em outros casos, mas afeta o teste `handshake req destroy test1`. Esse teste verifica se `handshake req cancel()`, seguido pelo fechamento do arquivo, realmente chama o método `->hp destroy`. O atraso em `fput(filp)` faz com que o teste falhe, pois não é possível garantir que o fechamento final esteja concluído antes de verificar o ponteiro. **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** O problema está relacionado a um estouro/subfluxo de inteiros nos cálculos de histerese no componente hwmon do kernel do Linux, especificamente no módulo lm90. Isso ocorre quando o valor de histerese é definido como MAX LONG e o limite crítico de temperatura é negativo. O problema foi resolvido utilizando a função clamp val() para evitar estouro ou subfluxo ao definir a temperatura de histerese. **Recomendações** No momento, não há informações sobre uma versão mais recente que contenha uma correção para esta vulnerabilidade.