Monthly
Heap corruption in rust-openssl versions 0.10.50 through 0.10.79 allows attacker-controllable out-of-bounds writes of up to 7 bytes via the `CipherCtxRef::cipher_update_inplace` method when used with AES key-wrap-with-padding ciphers (EVP_aes_128_wrap_pad, EVP_aes_192_wrap_pad, EVP_aes_256_wrap_pad). The buffer sizing logic fails to account for AES-KWP's padding expansion when input length is not a multiple of 8, and because this occurs through FFI into native OpenSSL, Rust's memory safety guarantees do not prevent the corruption. This is a missed case from a prior fix for GHSA-xv59-967r-8726 in the same method; no public exploit has been identified at time of analysis.
Heap buffer over-write in Magick.NET's MIFF encoder triggers an out-of-bounds write when LZMA compression is active, due to a missing buffer size check (CWE-131). All Magick.NET NuGet package variants prior to version 14.13.1 are affected across multiple architectures (AnyCPU, x64, x86, arm64) and depth configurations (Q16, Q16-HDRI, OpenMP). An attacker who can deliver a crafted MIFF file for local processing can crash the consuming application, resulting in a complete availability impact. No public exploit code or CISA KEV listing exists at time of analysis, limiting real-world severity despite the heap write primitive.
Traffic Management Microkernel (TMM) crashes in F5 BIG-IP Virtual Edition and hardware platforms when SSL profiles are configured without hardware crypto acceleration, allowing remote unauthenticated attackers to cause denial of service via undisclosed traffic patterns. CVSS 7.5 (High) with network attack vector and no prerequisites. EPSS data not provided, no CISA KEV listing identified, indicating theoretical rather than observed exploitation. Vendor patch available per F5 advisory K000158082.
Linux kernel DMA API debug warnings in V3D rendering driver cause denial of service when CONFIG_DMA_API_DEBUG is enabled and V3D segment sizes exceed the default 64K maximum. The vulnerability affects systems using V3D graphics rendering (particularly Raspberry Pi 5) with debug DMA API enabled, allowing local authenticated users to trigger kernel warnings and potential system instability by creating V3D buffer objects larger than the device's claimed DMA segment size limit.
The `extract_hidden_states` speculative decoding proposer in vLLM returns a tensor with an incorrect shape after the first decode step, causing a `RuntimeError` that crashes the EngineCore process. The crash is triggered when any request in the batch uses sampling penalty parameters (`repetition_penalty`, `frequency_penalty`, or `presence_penalty`). A single request with a penalty parameter (e.g., `"repetition_penalty": 1.1`) is sufficient to crash the server. The crash is deterministic and immediate - no concurrency, race condition, or special workload is required. In vLLM v0.17.0, the `extract_hidden_states` proposer's `propose()` method returned `sampled_token_ids.unsqueeze(-1)`, producing a tensor of shape `(batch_size, 1)`. In [PR #37013](https://github.com/vllm-project/vllm/pull/37013) (first released in v0.18.0), the KV connector interface was refactored out of `propose()`. The return type changed from `tuple[Tensor, KVConnectorOutput | None]` to `Tensor`, and the `.unsqueeze(-1)` call was removed along with the KV connector output: ```python return sampled_token_ids.unsqueeze(-1), kv_connector_output # shape (batch_size, 1) return sampled_token_ids # shape (batch_size, 2) after first decode step ``` The refactor missed that `sampled_token_ids` changed semantics between the first and subsequent decode steps. After the first decode step, the rejection sampler allocates its output as `(batch_size, max_spec_len + 1)`. With `num_speculative_tokens=1`, this produces shape `(batch_size, 2)` instead of the expected `(batch_size, 1)`, causing a broadcast shape mismatch during penalty application. Any vLLM deployment between v0.18.0 and v0.19.1 (inclusive) configured with `extract_hidden_states` speculative decoding is affected. A single API request containing any penalty parameter immediately and permanently crashes the EngineCore process, resulting in complete loss of service availability. Fixed in [PR #38610](https://github.com/vllm-project/vllm/pull/38610), first included in vLLM v0.20.0. The fix slices the return value to `sampled_token_ids[:, :1]`, ensuring the correct `(batch_size, 1)` shape regardless of the rejection sampler's output dimensions. - Upgrade to vLLM v0.20.0 or later. - If upgrading is not possible, avoid using `extract_hidden_states` as the speculative decoding method on affected versions. - Alternatively, reject or strip penalty parameters (`repetition_penalty`, `frequency_penalty`, `presence_penalty`) from incoming requests at an API gateway before they reach vLLM.
Denial of service in Linux kernel xfrm (IPsec transform) subsystem allows local authenticated attackers to trigger a kernel panic via improper netlink message size calculation when handling XFRM_MSG_GETAE requests for states with interface ID set. The xfrm_aevent_msgsize() function fails to account for XFRMA_IF_ID attribute space, causing build_aevent() to exceed buffer bounds and hit a BUG_ON assertion, resulting in kernel crash. EPSS exploitation probability is very low at 0.02% despite the local attack vector, suggesting limited real-world impact.
Remote code execution in Delta Electronics AS320T industrial automation server allows unauthenticated network attackers to trigger memory corruption via malformed GET/PUT requests to the web service. The incorrect buffer size calculation (CWE-131) enables stack-based overflow attacks against network-exposed management interfaces. With CVSS 9.8 (AV:N/AC:L/PR:N/UI:N) indicating trivial exploitation conditions and CRITICAL severity, this vulnerability represents an immediate risk to industrial control systems deploying this Delta OT product, though no public exploit or active exploitation confirmed at time of analysis.
Memory corruption in rust-openssl's key derivation functions allows heap or stack buffer overflow when applications pass undersized buffers to Deriver::derive or PkeyCtxRef::derive on OpenSSL 1.1.x. The vulnerability affects X25519, X448, DH, and HKDF-extract operations where OpenSSL ignores the caller-specified buffer length and unconditionally writes the full shared secret, causing safe Rust code to trigger memory corruption. Vendor patch available in v0.10.78; OpenSSL 3.x deployments are not affected as newer providers correctly validate buffer lengths.
{ item_typ.len() * elem_count } ``` For the **outer** array, `allocate_external_call_results()` correctly uses `define_variable()`, which internally calls `allocate_value_with_type()`. This function applies the formula above, producing the correct semi-flattened size. However, for **nested** arrays, `allocate_foreign_call_result_array()` contains a bug. When it encounters a nested `Type::Array(types, nested_size)`, it calls: ```rust Type::Array(_, nested_size) => { let inner_array = self.brillig_context.allocate_brillig_array(*nested_size as usize); // .... } ``` The pattern `Type::Array(_, nested_size)` discards the inner types with `_` and uses only `nested_size`, the **semantic length** of the nested array (the number of logical elements), not the semi-flattened size. For simple element types this works correctly, but for composite element types it under-allocates. Consider a nested array of type `[(u32, u32); 3]`: - Semantic length: 3 (three tuples) - Element size: 2 (each tuple has two fields) - Required semi-flattened size: 6 memory slots The current code passes `3` to `allocate_brillig_array()`, which then calls `codegen_initialize_array()`. This function allocates `array.size + ARRAY_META_COUNT` slots, only 4 slots instead of the required 7 (6 data + 1 metadata). When the VM executes the foreign call and writes 6 values plus metadata, it overwrites adjacent heap memory. Foreign calls returning nested arrays of tuples or other composite types corrupt the Brillig VM heap. Multiply the semantic length by the number of element types when allocating nested arrays. Extract the inner types from the pattern and replace the `nested_size` argument to `allocate_brillig_array()` with `types.len() * nested_size` to compute the semi-flattened size. Alternatively, reuse the existing `compute_array_length()` helper function to maintain consistency with outer array allocation.
NEMU (OpenXiangShan/NEMU) before v2025.12.r2 contains an improper instruction-validation flaw in its RISC-V Vector (RVV) decoder. The decoder does not correctly validate the funct3 field when decoding vsetvli/vsetivli/vsetvl, allowing certain invalid OP-V instruction encodings to be misinterpreted and executed as vset* configuration instructions rather than raising an illegal-instruction exception. This can be exploited by providing crafted RISC-V binaries to cause incorrect trap behavior, architectural state corruption/divergence, and potential denial of service in systems that rely on NEMU for correct execution or sandboxing.
Heap corruption in rust-openssl versions 0.10.50 through 0.10.79 allows attacker-controllable out-of-bounds writes of up to 7 bytes via the `CipherCtxRef::cipher_update_inplace` method when used with AES key-wrap-with-padding ciphers (EVP_aes_128_wrap_pad, EVP_aes_192_wrap_pad, EVP_aes_256_wrap_pad). The buffer sizing logic fails to account for AES-KWP's padding expansion when input length is not a multiple of 8, and because this occurs through FFI into native OpenSSL, Rust's memory safety guarantees do not prevent the corruption. This is a missed case from a prior fix for GHSA-xv59-967r-8726 in the same method; no public exploit has been identified at time of analysis.
Heap buffer over-write in Magick.NET's MIFF encoder triggers an out-of-bounds write when LZMA compression is active, due to a missing buffer size check (CWE-131). All Magick.NET NuGet package variants prior to version 14.13.1 are affected across multiple architectures (AnyCPU, x64, x86, arm64) and depth configurations (Q16, Q16-HDRI, OpenMP). An attacker who can deliver a crafted MIFF file for local processing can crash the consuming application, resulting in a complete availability impact. No public exploit code or CISA KEV listing exists at time of analysis, limiting real-world severity despite the heap write primitive.
Traffic Management Microkernel (TMM) crashes in F5 BIG-IP Virtual Edition and hardware platforms when SSL profiles are configured without hardware crypto acceleration, allowing remote unauthenticated attackers to cause denial of service via undisclosed traffic patterns. CVSS 7.5 (High) with network attack vector and no prerequisites. EPSS data not provided, no CISA KEV listing identified, indicating theoretical rather than observed exploitation. Vendor patch available per F5 advisory K000158082.
Linux kernel DMA API debug warnings in V3D rendering driver cause denial of service when CONFIG_DMA_API_DEBUG is enabled and V3D segment sizes exceed the default 64K maximum. The vulnerability affects systems using V3D graphics rendering (particularly Raspberry Pi 5) with debug DMA API enabled, allowing local authenticated users to trigger kernel warnings and potential system instability by creating V3D buffer objects larger than the device's claimed DMA segment size limit.
The `extract_hidden_states` speculative decoding proposer in vLLM returns a tensor with an incorrect shape after the first decode step, causing a `RuntimeError` that crashes the EngineCore process. The crash is triggered when any request in the batch uses sampling penalty parameters (`repetition_penalty`, `frequency_penalty`, or `presence_penalty`). A single request with a penalty parameter (e.g., `"repetition_penalty": 1.1`) is sufficient to crash the server. The crash is deterministic and immediate - no concurrency, race condition, or special workload is required. In vLLM v0.17.0, the `extract_hidden_states` proposer's `propose()` method returned `sampled_token_ids.unsqueeze(-1)`, producing a tensor of shape `(batch_size, 1)`. In [PR #37013](https://github.com/vllm-project/vllm/pull/37013) (first released in v0.18.0), the KV connector interface was refactored out of `propose()`. The return type changed from `tuple[Tensor, KVConnectorOutput | None]` to `Tensor`, and the `.unsqueeze(-1)` call was removed along with the KV connector output: ```python return sampled_token_ids.unsqueeze(-1), kv_connector_output # shape (batch_size, 1) return sampled_token_ids # shape (batch_size, 2) after first decode step ``` The refactor missed that `sampled_token_ids` changed semantics between the first and subsequent decode steps. After the first decode step, the rejection sampler allocates its output as `(batch_size, max_spec_len + 1)`. With `num_speculative_tokens=1`, this produces shape `(batch_size, 2)` instead of the expected `(batch_size, 1)`, causing a broadcast shape mismatch during penalty application. Any vLLM deployment between v0.18.0 and v0.19.1 (inclusive) configured with `extract_hidden_states` speculative decoding is affected. A single API request containing any penalty parameter immediately and permanently crashes the EngineCore process, resulting in complete loss of service availability. Fixed in [PR #38610](https://github.com/vllm-project/vllm/pull/38610), first included in vLLM v0.20.0. The fix slices the return value to `sampled_token_ids[:, :1]`, ensuring the correct `(batch_size, 1)` shape regardless of the rejection sampler's output dimensions. - Upgrade to vLLM v0.20.0 or later. - If upgrading is not possible, avoid using `extract_hidden_states` as the speculative decoding method on affected versions. - Alternatively, reject or strip penalty parameters (`repetition_penalty`, `frequency_penalty`, `presence_penalty`) from incoming requests at an API gateway before they reach vLLM.
Denial of service in Linux kernel xfrm (IPsec transform) subsystem allows local authenticated attackers to trigger a kernel panic via improper netlink message size calculation when handling XFRM_MSG_GETAE requests for states with interface ID set. The xfrm_aevent_msgsize() function fails to account for XFRMA_IF_ID attribute space, causing build_aevent() to exceed buffer bounds and hit a BUG_ON assertion, resulting in kernel crash. EPSS exploitation probability is very low at 0.02% despite the local attack vector, suggesting limited real-world impact.
Remote code execution in Delta Electronics AS320T industrial automation server allows unauthenticated network attackers to trigger memory corruption via malformed GET/PUT requests to the web service. The incorrect buffer size calculation (CWE-131) enables stack-based overflow attacks against network-exposed management interfaces. With CVSS 9.8 (AV:N/AC:L/PR:N/UI:N) indicating trivial exploitation conditions and CRITICAL severity, this vulnerability represents an immediate risk to industrial control systems deploying this Delta OT product, though no public exploit or active exploitation confirmed at time of analysis.
Memory corruption in rust-openssl's key derivation functions allows heap or stack buffer overflow when applications pass undersized buffers to Deriver::derive or PkeyCtxRef::derive on OpenSSL 1.1.x. The vulnerability affects X25519, X448, DH, and HKDF-extract operations where OpenSSL ignores the caller-specified buffer length and unconditionally writes the full shared secret, causing safe Rust code to trigger memory corruption. Vendor patch available in v0.10.78; OpenSSL 3.x deployments are not affected as newer providers correctly validate buffer lengths.
{ item_typ.len() * elem_count } ``` For the **outer** array, `allocate_external_call_results()` correctly uses `define_variable()`, which internally calls `allocate_value_with_type()`. This function applies the formula above, producing the correct semi-flattened size. However, for **nested** arrays, `allocate_foreign_call_result_array()` contains a bug. When it encounters a nested `Type::Array(types, nested_size)`, it calls: ```rust Type::Array(_, nested_size) => { let inner_array = self.brillig_context.allocate_brillig_array(*nested_size as usize); // .... } ``` The pattern `Type::Array(_, nested_size)` discards the inner types with `_` and uses only `nested_size`, the **semantic length** of the nested array (the number of logical elements), not the semi-flattened size. For simple element types this works correctly, but for composite element types it under-allocates. Consider a nested array of type `[(u32, u32); 3]`: - Semantic length: 3 (three tuples) - Element size: 2 (each tuple has two fields) - Required semi-flattened size: 6 memory slots The current code passes `3` to `allocate_brillig_array()`, which then calls `codegen_initialize_array()`. This function allocates `array.size + ARRAY_META_COUNT` slots, only 4 slots instead of the required 7 (6 data + 1 metadata). When the VM executes the foreign call and writes 6 values plus metadata, it overwrites adjacent heap memory. Foreign calls returning nested arrays of tuples or other composite types corrupt the Brillig VM heap. Multiply the semantic length by the number of element types when allocating nested arrays. Extract the inner types from the pattern and replace the `nested_size` argument to `allocate_brillig_array()` with `types.len() * nested_size` to compute the semi-flattened size. Alternatively, reuse the existing `compute_array_length()` helper function to maintain consistency with outer array allocation.
NEMU (OpenXiangShan/NEMU) before v2025.12.r2 contains an improper instruction-validation flaw in its RISC-V Vector (RVV) decoder. The decoder does not correctly validate the funct3 field when decoding vsetvli/vsetivli/vsetvl, allowing certain invalid OP-V instruction encodings to be misinterpreted and executed as vset* configuration instructions rather than raising an illegal-instruction exception. This can be exploited by providing crafted RISC-V binaries to cause incorrect trap behavior, architectural state corruption/divergence, and potential denial of service in systems that rely on NEMU for correct execution or sandboxing.