Pawel Wieczorkiewicz

When SMT is enabled, certain AMD processors may speculatively execute instructions using a target from the sibling thread after an SMT mode switch, potentially resulting in information disclosure. This issue is related to errors occurring after a core exits the C0 sleep state. Exploitation of this issue may allow an attacker to disclose protected information, including access to the return address predictor cache.

O problema está relacionado à implementação do mecanismo Indirect Branch Prediction Barrier (IBPB) no microcódigo do processador AMD, o que pode levar a uma possível divulgação de informações devido à limpeza incorreta da pilha de endereços de retorno (RAS). Isso poderia permitir que um invasor obtivesse informações confidenciais usando um canal lateral. A vulnerabilidade está sendo explorada ativamente.

O problema está relacionado à execução especulativa em CPUs AMD, o que pode permitir o vazamento de dados por meio da execução transitória além de ramificações diretas incondicionais. Isso poderia levar à divulgação de áreas arbitrárias da memória. Por exemplo, uma exploração de prova de conceito foi desenvolvida para determinar layouts de endereços e contornar o mecanismo de proteção KASLR (randomização do layout do espaço de endereços do kernel) ao executar código não privilegiado no subsistema do kernel ePBF. Outros cenários de ataque também podem levar ao vazamento do conteúdo da memória do kernel.

O problema está relacionado a um estouro de buffer na memória durante a leitura de um contrato de alocação (lease), o que pode causar uma negação de serviço. O resultado ao encontrar a falha varia de acordo com o componente afetado, se o pacote foi compilado como binário de 32 bits ou 64 bits e se o sinalizador do compilador -fstack-protection-strong foi usado durante a compilação. No dhclient, é possível causar uma falha em um sistema de 32 bits ao ler um lease inválido, levando a problemas de conectividade de rede. No dhcpd, quando executado no modo DHCPv4 ou DHCPv6, o servidor pode encerrar ou excluir leases de forma incorreta.

Foi detectada uma falha no Xen em que o xenstored e os convidados se comunicam por meio de uma página de memória compartilhada utilizando um protocolo específico. Quando um convidado viola esse protocolo, o xenstored interrompe a conexão com esse convidado, resultando nas mesmas ações que ocorreriam se o convidado tivesse sido destruído, incluindo o envio de um evento `@releaseDomain`. Isso pode levar a um domínio zumbi, no qual os mapeamentos de memória desse convidado não serão removidos devido à falta do evento. Um convidado malicioso pode bloquear recursos do host por um período após sua própria morte. Vidados com um modelo de dispositivo de domínio stub podem eventualmente travar o xenstored, resultando em uma negação de serviço mais grave. Apenas a variante C do Xenstore é afetada, e somente convidados HVM com um modelo de dispositivo stubdom podem causar um DoS grave.

Foi descoberta uma falha em alguns sistemas operacionais, como Linux, FreeBSD e NetBSD, que processam eventos de monitoramento usando um único thread. Se os eventos forem recebidos mais rapidamente do que o thread é capaz de processar, eles serão enfileirados. Como a fila não tem limite, um convidado pode ser capaz de provocar um OOM no backend. Todos os sistemas com um dom0 FreeBSD, Linux ou NetBSD (qualquer versão) estão vulneráveis.

Um problema no backend de blocos PV do kernel Linux pode fazer com que um ponteiro seja reutilizado após ter sido liberado. Isso ocorre quando o manipulador de threads do kernel não tem tempo para redefinir `ring->xenblkd` como NULL se o front-end alternar rapidamente entre os estados de conexão e desconexão. Um convidado com comportamento inadequado pode provocar uma falha no dom0 ao conectar/desconectar continuamente um front-end de bloco, o que pode levar à escalada de privilégios e vazamentos de informações. Esta falha afeta sistemas com um blkback do Linux.

Uma falha no Xen permite que usuários do sistema operacional convidado provoquem uma negação de serviço devido a um tratamento incorreto de continuação na função GNTTABOP copy. Espera-se que as operações da tabela de concessões retornem 0 em caso de sucesso e um número negativo em caso de erros. No entanto, um caminho através do tratamento de cópia de concessão pode retornar sucesso ao chamador sem que nenhuma ação seja tomada, deixando os campos de status das operações individuais não inicializados. Isso pode resultar em comportamento errôneo no chamador de GNTTABOP copy. Um convidado com bug ou malicioso pode construir sua tabela de concessões para atingir o caminho de saída incorreto quando um domínio backend tenta copiar uma concessão, retornando sucesso sem fazer nada, o que pode causar travamentos ou outro comportamento incorreto.

**Nome do software vulnerável e versões afetadas: Processadores Intel® (versões afetadas não especificadas) Descrição: O problema está relacionado ao encaminhamento inadequado de dados em alguns caches de dados dos Processadores Intel(R), o que pode permitir que um usuário autenticado potencialmente cause a divulgação de informações por meio de acesso local. Isso se deve a erros na sincronização de dados na memória cache. Recomendações: No momento, não há informações sobre uma versão mais recente que contenha uma correção para essa vulnerabilidade.