Sprabhav7

Um estouro de buffer baseado em pilha ocorre na pilha de protocolo Bluetooth do Linux ao processar um pacote Extended Inquiry Response (EIR). Um invasor remoto dentro do alcance do rádio Bluetooth pode disparar este problema durante a descoberta do Bluetooth enviando um pacote especialmente criado, o que afeta a função `name2utf8()`. Isso pode resultar em uma Negação de Serviço (DoS) ao travar o serviço bluetoothd ou potencialmente permitir a execução de código arbitrário.

Um estouro de buffer baseado em heap ocorre no agendador do CUPS ao construir strings de opção de filtro a partir de atributos de trabalho. Este problema está localizado na função `get options()` e pode permitir que um invasor remoto execute código arbitrário.

Netty, an asynchronous, event-driven network application framework, is susceptible to a Denial of Service (DoS) attack. A remote user can exploit this by sending a flood of `CONTINUATION` frames to a Netty HTTP/2 server. The server does not limit the number of `CONTINUATION` frames it accepts, and existing size-based protections are bypassed when zero-byte frames are used. This allows an attacker to cause excessive CPU consumption with minimal bandwidth, rendering the server unresponsive. The issue resides in the `DefaultHttp2FrameReader` component, specifically within the `verifyContinuationFrame()` function, which lacks a frame count check. The `HeadersBlockBuilder.addFragment()` function also allows bypassing the byte limit with zero-byte frames.

O jackson-core contém abstrações centrais de analisador e gerador incrementais ("streaming") de baixo nível. O `UTF8DataInputJsonParser` e o `ReaderBasedJsonParser` contornam a restrição `maxNestingDepth` definida em `StreamReadConstraints`. Isso permite que um usuário forneça um documento JSON com aninhamento excessivo, o que pode causar um `StackOverflowError` quando a estrutura é processada, levando a uma Negação de Serviço (DoS). A restrição `maxNestingDepth` possui um valor padrão de 500. O problema foi corrigido adicionando uma verificação que lança uma `StreamConstraintsException` caso o limite seja atingido.

O analisador JSON não bloqueante (assíncrono) no jackson-core não impõe a restrição `maxNumberLength` definida em `StreamReadConstraints`. Isso ocorre porque o caminho de análise assíncrona em `NonBlockingUtf8JsonParserBase` e classes relacionadas não invoca os métodos de validação de comprimento de número. Especificamente, métodos como ` finishNumberIntegralPart()` acumulam dígitos no `TextBuffer` sem verificações, e o ` valueComplete()` não chama `resetInt()` ou `resetFloat()`, onde `validateIntegerLength()` e `validateFPLength()` são executados. Um invasor pode enviar um documento JSON contendo um token numérico de comprimento arbitrário, levando à alocação excessiva de memória no `TextBuffer` e a um possível `OutOfMemoryError`. Além disso, se a aplicação chamar `getBigIntegerValue()` ou `getDecimalValue()`, a JVM pode sofrer exaustão de CPU devido ao processamento de BigInteger em O(n^2), resultando em negação de serviço.