Affected: Alpaquita:23: grpc, Alpaquita:stream: grpc, BellSoft Hardened Containers:stream: grpc

Affected: Homebrew: dstack

gRPC contains a vulnerability that allows hpack table accounting errors could lead to unwanted disconnects between clients and servers in exceptional cases/ Three vectors were found that allow the following DOS attacks:

- Unbounded memory buffering in the HPACK parser - Unbounded CPU consumption in the HPACK parser

The unbounded CPU consumption is down to a copy that occurred per-input-block in the parser, and because that could be unbounded due to the memory copy bug we end up with an O(n^2) parsing loop, with n selected by the client.

The unbounded memory buffering bugs:

- The header size limit check was behind the string reading code, so we needed to first buffer up to a 4 gigabyte string before rejecting it as longer than 8 or 16kb. - HPACK varints have an encoding quirk whereby an infinite number of 0’s can be added at the start of an integer. gRPC’s hpack parser needed to read all of them before concluding a parse. - gRPC’s metadata overflow check was performed per frame, so that the following sequence of frames could cause infinite buffering: HEADERS: containing a: 1 CONTINUATION: containing a: 2 CONTINUATION: containing a: 3 etc…

gRPC contains a vulnerability that allows hpack table accounting errors could lead to unwanted disconnects between clients and servers in exceptional cases/ Three vectors were found that allow the following DOS attacks:

- Unbounded memory buffering in the HPACK parser - Unbounded CPU consumption in the HPACK parser

The unbounded CPU consumption is down to a copy that occurred per-input-block in the parser, and because that could be unbounded due to the memory copy bug we end up with an O(n^2) parsing loop, with n selected by the client.

The unbounded memory buffering bugs:

- The header size limit check was behind the string reading code, so we needed to first buffer up to a 4 gigabyte string before rejecting it as longer than 8 or 16kb. - HPACK varints have an encoding quirk whereby an infinite number of 0’s can be added at the start of an integer. gRPC’s hpack parser needed to read all of them before concluding a parse. - gRPC’s metadata overflow check was performed per frame, so that the following sequence of frames could cause infinite buffering: HEADERS: containing a: 1 CONTINUATION: containing a: 2 CONTINUATION: containing a: 3 etc…

Affected: PyPI: grpcio, RubyGems: grpc

gRPC contains a vulnerability that allows hpack table accounting errors could lead to unwanted disconnects between clients and servers in exceptional cases/ Three vectors were found that allow the following DOS attacks:

- Unbounded memory buffering in the HPACK parser - Unbounded CPU consumption in the HPACK parser

The unbounded CPU consumption is down to a copy that occurred per-input-block in the parser, and because that could be unbounded due to the memory copy bug we end up with an O(n^2) parsing loop, with n selected by the client.

The unbounded memory buffering bugs:

- The header size limit check was behind the string reading code, so we needed to first buffer up to a 4 gigabyte string before rejecting it as longer than 8 or 16kb. - HPACK varints have an encoding quirk whereby an infinite number of 0’s can be added at the start of an integer. gRPC’s hpack parser needed to read all of them before concluding a parse. - gRPC’s metadata overflow check was performed per frame, so that the following sequence of frames could cause infinite buffering: HEADERS: containing a: 1 CONTINUATION: containing a: 2 CONTINUATION: containing a: 3 etc…

Issue summary: The POLY1305 MAC (message authentication code) implementation contains a bug that might corrupt the internal state of applications on the Windows 64 platform when running on newer X86_64 processors supporting the AVX512-IFMA instructions. Impact summary: If in an application that uses the OpenSSL library an attacker can influence whether the POLY1305 MAC algorithm is used, the application state might be corrupted with various application dependent consequences. The POLY1305 MAC (message authentication code) implementation in OpenSSL does not save the contents of non-volatile XMM registers on Windows 64 platform when calculating the MAC of data larger than 64 bytes. Before returning to the caller all the XMM registers are set to zero rather than restoring their previous content. The vulnerable code is used only on newer x86_64 processors supporting the AVX512-IFMA instructions. The consequences of this kind of internal application state corruption can be various - from no consequences, if the calling application does not depend on the contents of non-volatile XMM registers at all, to the worst consequences, where the attacker could get complete control of the application process. However given the contents of the registers are just zeroized so the attacker cannot put arbitrary values inside, the most likely consequence, if any, would be an incorrect result of some application dependent calculations or a crash leading to a denial of service. The POLY1305 MAC alg…

Affected: PyPI: grpcio

gRPC contains a vulnerability that allows hpack table accounting errors could lead to unwanted disconnects between clients and servers in exceptional cases/ Three vectors were found that allow the following DOS attacks:

- Unbounded memory buffering in the HPACK parser - Unbounded CPU consumption in the HPACK parser

The unbounded CPU consumption is down to a copy that occurred per-input-block in the parser, and because that could be unbounded due to the memory copy bug we end up with an O(n^2) parsing loop, with n selected by the client.

The unbounded memory buffering bugs:

- The header size limit check was behind the string reading code, so we needed to first buffer up to a 4 gigabyte string before rejecting it as longer than 8 or 16kb. - HPACK varints have an encoding quirk whereby an infinite number of 0’s can be added at the start of an integer. gRPC’s hpack parser needed to read all of them before concluding a parse. - gRPC’s metadata overflow check was performed per frame, so that the following sequence of frames could cause infinite buffering: HEADERS: containing a: 1 CONTINUATION: containing a: 2 CONTINUATION: containing a: 3 etc…

python-wheel: remote attackers can cause denial of service via attacker controlled input to wheel cli gRPC: Reachable Assertion gRPC: sensitive information disclosure gRPC: hpack table accounting errors can lead to denial of service

Affected: Ubuntu:16.04:LTS: grpc, Ubuntu:18.04:LTS: grpc, Ubuntu:20.04:LTS: grpc, Ubuntu:22.04:LTS: grpc, Ubuntu:24.04:LTS: grpc, Ubuntu:25.10: grpc, Ubuntu:26.04:LTS: grpc

gRPC contains a vulnerability that allows hpack table accounting errors could lead to unwanted disconnects between clients and servers in exceptional cases/ Three vectors were found that allow the following DOS attacks: - Unbounded memory buffering in the HPACK parser - Unbounded CPU consumption in the HPACK parser The unbounded CPU consumption is down to a copy that occurred per-input-block in the parser, and because that could be unbounded due to the memory copy bug we end up with an O(n^2) parsing loop, with n selected by the client. The unbounded memory buffering bugs: - The header size limit check was behind the string reading code, so we needed to first buffer up to a 4 gigabyte string before rejecting it as longer than 8 or 16kb. - HPACK varints have an encoding quirk whereby an infinite number of 0’s can be added at the start of an integer. gRPC’s hpack parser needed to read all of them before concluding a parse. - gRPC’s metadata overflow check was performed per frame, so that the following sequence of frames could cause infinite buffering: HEADERS: containing a: 1 CONTINUATION: containing a: 2 CONTINUATION: containing a: 3 etc…

Gvariant offset table entry size is not checked in is_normal() G_variant_byteswap() can take a long time with some non-normal inputs Gvariant deserialisation does not match spec for non-normal data Glibc: dos due to memory leak in getaddrinfo.c Glibc: buffer overflow in ld.so leading to privilege escalation Gnutls: incomplete fix for cve-2023-5981 Gnutls: rejects certificate chain with distributed trust Denial-of-Service in gRPC Information leak in gRPC Denial-of-Service in gRPC Denial of Service in gRPC Core Libssh: proxycommand/proxyjump features allow injection of malicious code through hostname Arbitrary Memory Disclosure through CPU Side-Channel Attacks (Retbleed) Incorrect cipher key & IV length processing POLY1305 MAC implementation corrupts XMM registers on Windows Excessive time spent checking DH q parameter value SQLite SQLite3 make alltest sqlite3session.c sessionReadRecord heap-based overflow NULL Pointer Dereference in vim/vim Heap-based Buffer Overflow in vim/vim Use After Free in vim/vim Heap-based Buffer Overflow in vim/vim Integer Overflow or Wraparound in vim/vim Use After Free in vim/vim Untrusted Search Path in vim/vim Out-of-bounds Write in vim/vim Use After Free in vim/vim Heap-based Buffer Overflow in vim/vim Use After Free in vim/vim Heap-based Buffer Overflow in vim/vim Use-After-Free in win_close() in vim overflow in shift_line in vim Vim has heap-use-after-free at /src/charset.c:1770:12 in skipwhite Integer Overflow in :history command in Vim

Ein Angreifer kann mehrere Schwachstellen in Juniper JUNOS ausnutzen, um einen Denial of Service zu verursachen, Informationen offenzulegen, Privilegien zu erweitern und Sicherheitsmechanismen inklusive zu umgehen.