Br0Nzu

**Nome do Software Vulnerável e Versões Afetadas** OpenEXR versões anteriores a 3.2.11 OpenEXR versões 3.3.0 a 3.3.12 OpenEXR versões 3.4.0 a 3.4.13 **Description** Um arquivo EXR manipulado com um `dataWindow.min` diferente de zero pode fazer com que a função `TypedFlatImageChannel::row()` retorne um ponteiro de heap inválido. Isso resulta em gravações fora dos limites (out-of-bounds) ou de uso após a liberação (use-after-free) quando um aplicativo grava linhas por meio da função `FlatHalfChannel::row()`. Este problema afeta ferramentas, conversores, componentes de pipeline de renderização ou serviços de processamento de imagem que aceitam arquivos EXR não confiáveis e utilizam a função `FlatHalfChannel::row()` em imagens carregadas. **Recommendations** Atualizar para a versão 3.2.11. Atualizar para a versão 3.3.13. Atualizar para a versão 3.4.14.

**Nome do Software Vulnerável e Versões Afetadas** OpenEXR versões anteriores a 3.2.11 OpenEXR versões 3.3.0 até 3.3.12 OpenEXR versões 3.4.0 até 3.4.13 **Description** Uma gravação fora dos limites do heap (heap out-of-bounds write) ocorre em compilações de 32 bits/ILP32 ao processar um arquivo EXR tiled manipulado através da API RGBA `TiledRgbaInputFile`. O problema surge quando um arquivo contém um `dataWindow` pequeno de 40x40, mas um tamanho de tile grande de 65537x65537, fazendo com que o cálculo do tamanho do buffer de conversão de tile `Array2D<Rgba>` sofra um estouro (overflow). Isso resulta na alocação de um buffer de heap subdimensionado, levando a uma operação de gravação que excede a memória alocada durante a decodificação do tile. **Recommendations** Atualizar para a versão 3.2.11. Atualizar para a versão 3.3.13. Atualizar para a versão 3.4.14.

**Nome do Software Vulnerável e Versões Afetadas** OpenEXR versões 3.3.0 até 3.3.12 OpenEXR versões 3.4.0 até 3.4.13 **Description** Ocorre uma gravação fora dos limites do heap (heap out-of-bounds write) quando a ferramenta `exrmetrics` processa um arquivo EXR de scanline profunda especialmente manipulado. Isso acontece ao utilizar opções de conversão de pixel como `--pixelmode float` ou `--bench`, pois a função `DeepSlice` solicita saída FLOAT enquanto os buffers de amostra de suporte são alocados usando o tamanho de elemento HALF de entrada. **Recommendations** Atualizar as versões 3.3.0 até 3.3.12 do OpenEXR para a versão 3.3.13. Atualizar as versões 3.4.0 até 3.4.13 do OpenEXR para a versão 3.4.14.

**Nome do Software Vulnerável e Versões Afetadas** OpenEXRUtil versões 3.3.0 a 3.3.12 OpenEXRUtil versões 3.4.0 a 3.4.12 **Description** A API `TypedDeepImageChannel<T>::row()` pode retornar um ponteiro fora dos limites quando uma imagem profunda possui uma origem dataWindow não nula. Isso ocorre porque o `ImfDeepImageChannel` utiliza dois modelos de coordenadas conflitantes: `at(x, y)` usa coordenadas absolutas, enquanto `row(r)` é documentado para acesso lógico baseado em 0. Consequentemente, se `dataWindow.min` for diferente de zero, `row(0)` aponta para fora da alocação ` sampleListPointers` em vez da primeira linha lógica. Isso resulta em uma leitura fora dos limites do heap e travamento, podendo permitir a divulgação de informações sob um layout de heap controlado. **Recommendations** Atualizar as versões 3.3.0 a 3.3.12 para a versão 3.3.13. Atualizar as versões 3.4.0 a 3.4.12 para a versão 3.4.13.

**Nome do Software Vulnerável e Versões Afetadas** OpenEXR versões anteriores a 3.2.11 OpenEXR versões 3.3.0 a 3.3.12 OpenEXR versões 3.4.0 a 3.4.13 **Description** Existe um problema onde a função `TypedDeepImageChannel::row()` pode retornar um ponteiro fora dos limites ao processar uma imagem EXR profunda manipulada com uma origem dataWindow diferente de zero. Isso ocorre porque a API combina o acesso a linhas baseado em zero com um ponteiro base ajustado por coordenadas absolutas, o que pode levar a um travamento ou divulgação limitada de informações. **Recommendations** Atualizar para a versão 3.2.11. Atualizar para a versão 3.3.13. Atualizar para a versão 3.4.14.

**Nome do Software Vulnerável e Versões Afetadas** OpenEXR versões anteriores a 3.2.11 OpenEXR versões 3.3.0 a 3.3.12 OpenEXR versões 3.4.0 a 3.4.13 **Description** Em builds ILP32, ocorre uma leitura fora dos limites ao processar um arquivo EXR de deep-tile não compactado e manipulado. Isso acontece porque o cálculo do tamanho da tabela de contagem de amostras em OpenEXRCore decoding.c sofre um wrap antes que a função `unpack sample table()` itere sobre as dimensões do tile controladas pelo atacante, o que pode levar a uma negação de serviço. **Recommendations** Atualizar para a versão 3.2.11. Atualizar para a versão 3.3.13. Atualizar para a versão 3.4.14.

**Nome do Software Vulnerável e Versões Afetadas** OpenEXR versões 3.1.0 até 3.2.10 OpenEXR versões 3.3.0 até 3.3.12 OpenEXR versões 3.4.0 até 3.4.13 **Description** Em builds ILP32, ocorre uma gravação fora dos limites (out-of-bounds write) ao processar um EXR de linha de varredura comprimido em B44 manipulado. Isso acontece porque o tamanho lógico do scratch é truncado antes da alocação, e a função `uncompress b44 impl()` realiza a gravação utilizando uma largura de canal controlada pelo invasor, resultando em corrupção de memória e negação de serviço. **Recommendations** Atualizar as versões 3.1.0 até 3.2.10 para a versão 3.2.11. Atualizar as versões 3.3.0 até 3.3.12 para a versão 3.3.13. Atualizar as versões 3.4.0 até 3.4.13 para a versão 3.4.14.

**Nome do Software Vulnerável e Versões Afetadas** OpenEXR versões 3.2.0 through 3.2.10 OpenEXR versões 3.3.0 through 3.3.12 OpenEXR versões 3.4.0 through 3.4.13 **Description** Em builds ILP32, ocorre uma leitura fora dos limites do heap ao processar uma imagem EXR compactada via RLE especialmente manipulada. O problema surge porque o tamanho descompactado de 64 bits é truncado antes da alocação em OpenEXRCore decoding.c, levando a função `unpack 32bit()` a ler além do buffer alocado, o que pode resultar em negação de serviço. **Recommendations** Atualizar as versões 3.2.0 through 3.2.10 para a versão 3.2.11. Atualizar as versões 3.3.0 through 3.3.12 para a versão 3.3.13. Atualizar as versões 3.4.0 through 3.4.13 para a versão 3.4.14.

**Nome do Software Vulnerável e Versões Afetadas** OpenEXR versões anteriores a 3.2.11 OpenEXR versões 3.3.0 até 3.3.12 OpenEXR versões 3.4.0 até 3.4.13 **Description** O OpenEXR, a implementação de referência para o formato de imagem EXR, está sujeito a um travamento ao processar um arquivo EXR especialmente manipulado. O problema ocorre quando a função `Imf::GetChannelsInMultiPartFile()` processa um arquivo com um atributo de cabeçalho multiView vazio, levando a função `Imf::viewFromChannelName()` a indexar um vetor vazio para um nome de canal sem ponto. **Recommendations** Atualizar para a versão 3.2.11. Atualizar para a versão 3.3.13. Atualizar para a versão 3.4.14.

**Nome do Software Vulnerável e Versões Afetadas** OpenEXR versões 3.3.0 through 3.3.12 OpenEXR versões 3.4.0 through 3.4.13 **Description** As ligações Python PyOpenEXR retornam dados obsoletos da heap ao ler um arquivo EXR de scanline profunda especialmente criado que utiliza canais RGB prefixados por camada. Ao usar a coalescência de canais padrão (onde `separate channels` é definido como `False`), o wrapper agrupa canais como left.R, left.G e left.B em um único array de amostra RGB. No entanto, o cálculo de deslocamento de faixa na função `setDeepSliceData()` reconhece apenas os nomes exatos não prefixados G, B e A. Consequentemente, canais prefixados como left.G e left.B são decodificados na faixa 0, deixando as faixas 1 e 2 não inicializadas. Uma aplicação Python que utilize a API OpenEXR.File padrão para ler arquivos EXR profundos não confiáveis pode expor conteúdos de heap não inicializados do mesmo processo ao processar os arrays de amostra NumPy resultantes, além de receber dados incorretos dos canais verde e azul. **Recommendations** Atualizar as versões 3.3.0 through 3.3.12 do OpenEXR para a versão 3.3.13. Atualizar as versões 3.4.0 through 3.4.13 do OpenEXR para a versão 3.4.14.

**Nome do Software Vulnerável e Versões Afetadas** OpenEXR versões 3.3.0 through 3.3.12 OpenEXR versões 3.4.0 through 3.4.13 **Description** O PyOpenEXR contém um estouro de buffer de heap desencadeado por uma colisão de chave de nome de canal entre canais RGB literais e prefixados. Quando a variável `separate channels` é definida como false, o PyOpenEXR utiliza a função `channelNameToRGBA()` para mapear nomes de canais físicos e coalescê-los em um array RGB compartilhado. Um arquivo EXR de scanline plana especialmente criado que contenha tanto um canal literal (ex: left) quanto canais prefixados (ex: left.R, left.G e left.B) causa uma colisão de nomes. Isso leva o wrapper a reutilizar um array NumPy bidimensional subdimensionado para as fatias RGB coalescidas, resultando em uma gravação fora dos limites quando `OpenEXR.File(path)` decodifica os pixels. **Recommendations** Atualizar as versões 3.3.0 through 3.3.12 para a versão 3.3.13. Atualizar as versões 3.4.0 through 3.4.13 para a versão 3.4.14.

**Nome do Software Vulnerável e Versões Afetadas** OpenEXR versões 3.3.0 through 3.3.12 OpenEXR versões 3.4.0 through 3.4.13 **Description** As ligações Python PyOpenEXR contêm uma gravação fora dos limites do heap (heap out-of-bounds write) que ocorre ao ler um arquivo EXR de scanline profunda especialmente manipulado. O problema surge quando um arquivo profundo declara um canal literal chamado `left` juntamente com canais RGB prefixados por camada `left.R`, `left.G` e `left.B`. O wrapper aloca um array de amostras profundas escalares para o canal `left` e, posteriormente, o reutiliza como destino para o grupo RGB. Como o leitor profundo registra fatias de amostra com um stride RGB em um armazenamento alocado com formato escalar, a decodificação das amostras grava além da memória alocada. A ativação disso por meio da API pública do Python `OpenEXR.File(path)` resulta em um estouro de buffer de heap, levando à corrupção de memória e ao travamento do sistema. **Recommendations** Atualizar as versões 3.3.0 through 3.3.12 para a versão 3.3.13. Atualizar as versões 3.4.0 through 3.4.13 para a versão 3.4.14.

**Nome do Software Vulnerável e Versões Afetadas** OpenEXR versões anteriores a 3.2.11 OpenEXR versões 3.3.0 a 3.3.12 OpenEXR versões 3.4.0 a 3.4.13 **Description** O utilitário `exrmultiview` pode realizar uma gravação fora dos limites do heap (heap out-of-bounds write) ao combinar dois arquivos EXR de scanline válidos se o `dataWindow` da união não estiver alinhado ao subsampling de canal de uma visão. O problema ocorre porque o utilitário aloca o armazenamento do canal amostrado usando um `union width` / `xSampling` truncado e, posteriormente, lê a entrada amostrada através de um Slice baseado na janela de união desalinhada. Isso pode ser acionado durante o processamento normal de arquivos de entrada manipulados, porém válidos. **Recommendations** Atualizar para a versão 3.2.11. Atualizar para a versão 3.3.13. Atualizar para a versão 3.4.14.

**Nome do Software Vulnerável e Versões Afetadas** OpenEXR versões anteriores a 3.2.11 OpenEXR versões 3.3.0 até 3.3.12 OpenEXR versões 3.4.0 até 3.4.13 **Description** A biblioteca OpenEXRUtil retorna um ponteiro fora dos limites a partir da API `SampleCountChannel::row()` quando uma imagem profunda possui uma origem `dataWindow` diferente de zero. Isso ocorre porque o acessador `row()` é baseado em 0, mas calcula seu endereço a partir de uma base interna deslocada para coordenadas de pixel absolutas, causando um conflito quando `dataWindow.min` não é zero. Se uma imagem profunda tiver uma origem vertical negativa grande, `row(0)` apontará para fora do buffer de contagem de amostras alocado. Um aplicativo que processe um arquivo EXR profundo malicioso pode realizar uma leitura fora dos limites, podendo causar a interrupção do processo ou a exposição de memória adjacente do heap. **Recommendations** Atualizar para a versão 3.2.11. Atualizar para a versão 3.3.13. Atualizar para a versão 3.4.14.