Roger Pau Monné

The issue arises from a mismatch in the IOMMU quarantine page table levels. On systems with no RAM above the 512GB mark, only 3 page-table levels are configured in the IOMMU, while the quarantine domain is initialized with 4 page table levels. This results in a device in quarantine mode gaining write access to the page destined to be a PDE, potentially leading to data leaks. The sink page the device gets read/write access to is no longer cleared between device assignment.

As diretrizes de invalidação de cache da especificação AMD-Vi estão incorretas em alguns hardwares, levando ao mau funcionamento dos dispositivos se alguns campos do DTE forem atualizados, mas o IOMMU TLB não for esvaziado. Isso pode causar mapeamentos DMA desatualizados, permitindo o acesso a regiões de memória indesejadas que não pertencem ao convidado.

The issue is related to the functionality of phantom functions in PCI devices, which can generate requests using the IDs of unpopulated functions, allowing a device to extend the number of outstanding requests. However, failure to set up the IOMMU context for these phantom functions is not fatal when the device is assigned, leading to potential security issues. This can result in the primary device being assigned to a guest, while some phantom functions are assigned to a different domain. The vulnerability is related to insufficient access control due to incorrect input validation when generating requests.

The issue arises in environments where host assisted address translation is necessary but Hardware Assisted Paging (HAP) is unavailable, causing Xen to run guests in shadow mode. Due to insufficient checks in hypervisor routines for shadow page handling, a guest with a passed-through PCI device can cause the hypervisor to access an arbitrary pointer partially under guest control.

O problema diz respeito ao armazenamento de senhas de PLC em texto simples no arquivo de configuração do CODESYS OPC DA Server, tornando essas senhas visíveis a todos os usuários autorizados do sistema que utilizam o Microsoft Windows.

O problema está relacionado à divulgação de informações no hipervisor Xen e no kernel Linux. Isso pode permitir que um invasor obtenha acesso não autorizado a informações protegidas ou provoque uma negação de serviço.

O problema está relacionado à divulgação de informações no hipervisor Xen e no kernel Linux. Isso pode permitir que um invasor obtenha acesso não autorizado a informações protegidas ou provoque uma negação de serviço.

O problema diz respeito a falhas no tratamento do IOMMU: RMRR (VT-d) e do mapeamento Unity (AMD-Vi). Certos dispositivos PCI em um sistema podem receber Regiões de Memória Reservadas para Intel VT-d ou intervalos de Mapeamento de Unidade para AMD-Vi, normalmente usados para tarefas da plataforma, como emulação USB legada. Como a finalidade exata dessas regiões é desconhecida, uma vez que um dispositivo associado a tal região esteja ativo, os mapeamentos dessas regiões precisam permanecer continuamente acessíveis pelo dispositivo. Esse requisito foi violado, podendo levar a um comportamento imprevisível, que varia de falhas no IOMMU até corrupção de memória.

O problema decorre de interações concorrentes entre o rastreamento de VRAM suja e as hiperchamadas de log sujo de paginação. A ativação do modo de log sujo realizada por `XEN DMOP track dirty vram` (anteriormente denominado `HVMOP track dirty vram` antes do Xen 4.9) é concorrente com hiperchamadas de log sujo em andamento. Uma chamada oportunamente sincronizada para `XEN DMOP track dirty vram` pode ativar o log sujo enquanto outra CPU ainda estiver no processo de desmontar as estruturas relacionadas a um modo de log sujo ativado anteriormente (`XEN DOMCTL SHADOW OP OFF`). Isso se deve à falta de bloqueio mutuamente exclusivo entre ambas as operações e pode levar à adição de entradas em slots já liberados, resultando em um vazamento de memória.

O problema diz respeito a questões relacionadas ao gerenciamento de IOMMU: RMRR (VT-d) e mapeamento Unity (AMD-Vi). Certos dispositivos PCI em um sistema podem receber Regiões de Memória Reservadas para Intel VT-d ou intervalos de Mapeamento de Unidade para AMD-Vi, normalmente usados para tarefas da plataforma, como emulação de USB legada. Como a finalidade exata dessas regiões é desconhecida, uma vez que um dispositivo associado a tal região esteja ativo, os mapeamentos dessas regiões precisam permanecer continuamente acessíveis pelo dispositivo. Esse requisito foi violado, resultando em comportamento imprevisível, que varia de falhas de IOMMU a corrupção de memória, quando ocorrem DMA ou interrupções subsequentes do dispositivo.

O problema diz respeito a falhas no tratamento da IOMMU (Unidade de Gerenciamento de Memória de Entrada-Saída) relacionadas ao RMRR (Relatório de Regiões de Memória Reservadas) para Intel VT-d e aos intervalos de mapeamento Unity para AMD-Vi. Certos dispositivos PCI podem receber Regiões de Memória Reservadas para tarefas da plataforma, como emulação USB legada. Como a finalidade dessas regiões é desconhecida, seus mapeamentos precisam permanecer acessíveis ao dispositivo uma vez que este esteja ativo. No entanto, esse requisito foi violado, podendo levar a comportamentos imprevisíveis, incluindo falhas na IOMMU e corrupção de memória.

O problema está relacionado a questões de gerenciamento do IOMMU: RMRR (VT-d) e mapeamento Unity (AMD-Vi). Certos dispositivos PCI em um sistema podem receber Regiões de Memória Reservadas para Intel VT-d ou intervalos de Mapeamento de Unidade para AMD-Vi, normalmente usados para tarefas da plataforma, como emulação USB legada. Como a finalidade exata dessas regiões é desconhecida, uma vez que um dispositivo associado a tal região esteja ativo, os mapeamentos dessas regiões precisam permanecer continuamente acessíveis pelo dispositivo. Esse requisito foi violado, resultando em comportamento imprevisível, que varia de falhas no IOMMU a corrupção de memória.

Foi descoberta uma falha no Xen ao transferir IRQs entre CPUs para distribuir a carga de processamento de IRQs. Os vetores de IRQ são alocados e desalocados dinamicamente nas CPUs relevantes. A desalocação deve ocorrer quando determinadas restrições são atendidas. Se essas condições não forem atendidas na primeira verificação, a CPU responsável pela verificação pode enviar uma interrupção a si mesma, na expectativa de que essa IRQ seja entregue somente após a condição que impede a limpeza ter sido resolvida. Para dois vetores de IRQ específicos, essa expectativa foi violada, resultando em um fluxo contínuo de auto-interrupções, o que torna a CPU efetivamente inutilizável. Um domínio com um dispositivo PCI repassado pode causar o travamento de uma CPU física, resultando em uma Negação de Serviço (DoS) para todo o host. Apenas sistemas x86 são vulneráveis, enquanto os sistemas Arm não são. O problema pode ser explorado por convidados com dispositivos PCI físicos repassados a eles.

A vulnerabilidade permite que usuários de sistemas operacionais convidados x86 Intel HVM provoquem uma negação de serviço no sistema operacional host ou, possivelmente, obtenham privilégios devido à gravação insuficiente no cache sob VT-d. Quando as tabelas de páginas são compartilhadas entre o IOMMU e a CPU, as alterações nelas exigem a atualização de ambas as TLBs. Além disso, os IOMMUs podem ser não coerentes e, portanto, antes de esvaziar os TLBs do IOMMU, o cache da CPU também precisa ser gravado de volta na memória após as alterações serem feitas. Um convidado mal-intencionado pode ser capaz de manter acesso DMA de leitura/gravação a quadros devolvidos ao pool livre do Xen e posteriormente reutilizados para outra finalidade. Não se pode descartar a possibilidade de falhas no host e escalonamento de privilégios. Apenas sistemas x86 Intel são afetados, e somente convidados x86 HVM que utilizem paginação assistida por hardware (HAP), tenham um dispositivo PCI repassado atribuído e tenham o compartilhamento de tabelas de páginas habilitado podem explorar a vulnerabilidade.

An issue allows x86 HVM guest OS users to cause a denial of service or possibly gain hypervisor privileges by setting up an HPET timer to deliver interrupts in IO-APIC mode. This can lead to an unexpectedly high interrupt number, array overrun, and hypervisor crash.

An issue allows x86 HVM guest OS users to obtain sensitive information from the host OS or an arbitrary guest OS. This occurs because intercepted I/O operations can cause a write of data from uninitialized hypervisor stack memory.

The issue is related to the `do mmu update` function in `arch/x86/mm.c`, which does not properly restrict updates to only PV page tables. This allows remote PV guests to cause a denial of service (NULL pointer dereference) by leveraging hardware emulation services for HVM guests using Hardware Assisted Paging (HAP).