| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Envoy is an open source edge and service proxy designed for cloud-native applications. From 1.34.0 until 1.35.13, 1.36.9, 1.37.5, and 1.38.3, PROXY Protocol v2 header generator emits TLVs beyond the maximum length of 65535 bytes, causing a mismatch between bytes written and the length field in the header. This can result in smuggled bytes on the upstream request. This vulnerability is fixed in 1.35.13, 1.36.9, 1.37.5, and 1.38.3. |
| When generating an ICMP Destination Unreachable or Packet Too Big response, the handler copies a portion of the original packet into the ICMP error body using the IP header's self-declared total length (ip_tot_len for IPv4, ip6_plen for IPv6) without validating it against the actual packet buffer size. A VM can send a short packet with an inflated IP length field that triggers an ICMP error (e.g., by hitting a reject ACL), causing ovn-controller to read heap memory beyond the valid packet data and include it in the ICMP response sent back to the VM. |
| Issue Summary: Cryptographic Message Services (CMS) processing fails to perform
sufficient input validation on the cipher and tag length fields of
AuthEnvelopedData containers, leading to various potential compromises.
Impact Summary: Attackers making use of these vulnerabilities may achieve
key-equivalent functionality for a given CMS recipient and/or bypass integrity
validation for a given message.
In one use case, an attacker may send a CMS message containing
AuthEnvelopedData with the cipher specified as a non-AEAD cipher. OpenSSL
erroneously allows this selection, and attempts to decrypt and validate the
message.
An on-path attacker who captures one legitimate AES-GCM AuthEnvelopedData
addressed to the victim can re-emit it with the recipientInfos set left
byte-for-byte intact, so the victim's private key still unwraps the genuine CEK
(the content-encryption key), but with the inner OID rewritten to AES-256-OFB
(Output Feedback Mode, an unauthenticated keystream mode) and with an
attacker-chosen IV and ciphertext. The victim initializes AES-256-OFB under the
real CEK, never consults the MAC field, and CMS_decrypt() returns success.
If the application under attack responds to the attacker with any indicator
showing success or failure of the decryption effort, it is possible for the
attacker to use this as an oracle to obtain key equivalent functionality for the
CEK used for the chosen recipient of the message.
In another use case, an attacker can reduce the tag length of the chosen AEAD
cipher for a given AuthEnvelopedData container to be a single byte long,
allowing an attacker to brute force CMS decryption, producing an integrity
bypass for applications that trust CMS_decrypt() to reject modified content.
The FIPS modules are not affected by this issue. |
| Side-channel information leakage in PerformanceAPIs in Google Chrome prior to 149.0.7827.53 allowed a remote attacker to leak cross-origin data via a crafted HTML page. (Chromium security severity: Low) |
| Side-channel information leakage in Paint in Google Chrome prior to 149.0.7827.53 allowed a remote attacker to leak cross-origin data via a crafted HTML page. (Chromium security severity: Low) |
| Side-channel information leakage in Forms in Google Chrome prior to 149.0.7827.53 allowed a remote attacker to leak cross-origin data via a crafted HTML page. (Chromium security severity: Medium) |
| A flaw has been found in warmcat libwebsockets up to 4.5.8. This issue affects the function lws_ssh_parse_plaintext of the file plugins/protocol_lws_ssh_base/sshd.c of the component SSH Protocol Handler. Executing a manipulation of the argument msg_len can lead to resource consumption. The attack may be launched remotely. The exploit has been published and may be used. This patch is called 3f9f0c6ecaf0e6f3f219d30632c5d1f2479d7498. A patch should be applied to remediate this issue. |
| OpenTelemetry eBPF Instrumentation provides eBPF instrumentation based on the OpenTelemetry standard. Prior to version 0.9.0, the per-CPU message-buffer fallback path uses a 256-byte backup buffer but preserves the original payload size, which can be up to 8KB. If a CPU mismatch occurs, OBI can read beyond the fallback buffer and leak adjacent memory into telemetry. This issue has been patched in version 0.9.0. |
| Improperly preserved integrity of hardware configuration state during a power save/restore operation in the AMD Secure Processor (ASP) could allow an attacker with the ability to write outside the trusted memory range (TMR) to change the execution flow of the Video Core Next (VCN) firmware potentially impacting confidentiality, integrity, or availability. |
| A flaw was found in OVN (Open Virtual Network). A remote attacker, by sending crafted DHCPv6 (Dynamic Host Configuration Protocol for IPv6) SOLICIT packets with an inflated Client ID length, could cause the ovn-controller to read beyond the bounds of a packet. This out-of-bounds read can lead to the disclosure of sensitive information stored in heap memory, which is then returned to the attacker's virtual machine port. |
| A buffer overflow exists in the Brotli library versions prior to 1.0.8 where an attacker controlling the input length of a "one-shot" decompression request to a script can trigger a crash, which happens when copying over chunks of data larger than 2 GiB. It is recommended to update your Brotli library to 1.0.8 or later. If one cannot update, we recommend to use the "streaming" API as opposed to the "one-shot" API, and impose chunk size limits. |
| mouse07410/asn1c is an ASN.1 compiler. In 1.4 and earlier, a memory safety vulnerability was identified in the OER decoding skeleton files generated by asn1c (specifically INTEGER_oer.c). When parsing a maliciously crafted, zero-length OER payload for a variable-length, non-negative INTEGER type, the decoder fails to validate the required bytes before extracting the Most Significant Bit (MSB). This forces a precise 1-byte Heap Out-of-Bounds (OOB) Read. Because asn1c generated code is primarily deployed to parse untrusted network inputs (such as V2X network protocols, 5G telecom headers, or X.509 certificates), when the decoder processes untrusted network-originated input, a remote attacker can exploit this to cause a Denial of Service (DoS) or trigger incorrect integer interpretation in downstream applications (e.g., protocol state poisoning or logic bypass). |
| FastNetMon Community Edition through 1.2.9 has out-of-bounds memory access because it incorrectly parses BGP path attributes with the extended length flag set. In src/bgp_protocol.hpp, the parse_raw_bgp_attribute() function correctly identifies when extended_length_bit is set and sets length_of_length_field to 2, but then reads only a single byte for the attribute value length (attribute_value_length = value[2] at line 173). Per RFC 4271 Section 4.3, when the Extended Length bit is set, the Attribute Length field is two octets and the value should be read as a 16-bit big-endian integer from value[2] and value[3]. As a result, any attribute longer than 255 bytes has its length silently truncated to the low byte (e.g., 300 bytes = 0x012C is read as 0x2C = 44 bytes). The remaining 256 bytes are then misinterpreted as subsequent attributes, causing cascading parse failures and potential out-of-bounds memory access. |
| An attacker sending tcp, il, rudp, rudp, or gre packets with a length less than the header size would trigger a kernel panic. |
| In the Linux kernel, the following vulnerability has been resolved:
ALSA: usb-audio: Check endpoint numbers at parsing Scarlett2 mixer interfaces
The Scarlett2 mixer quirk in USB-audio driver may hit a NULL
dereference when a malformed USB descriptor is passed, since it
assumes the presence of an endpoint in the parsed interface in
scarlett2_find_fc_interface(), as reported by fuzzer.
For avoiding the NULL dereference, just add the sanity check of
bNumEndpoints and skip the invalid interface. |
| Side-channel information leakage in Navigation in Google Chrome prior to 148.0.7778.168 allowed a remote attacker to leak cross-origin data via a crafted HTML page. (Chromium security severity: Medium) |
| In the Linux kernel, the following vulnerability has been resolved:
rxrpc: fix oversized RESPONSE authenticator length check
rxgk_verify_response() decodes auth_len from the packet and is supposed
to verify that it fits in the remaining bytes. The existing check is
inverted, so oversized RESPONSE authenticators are accepted and passed
to rxgk_decrypt_skb(), which can later reach skb_to_sgvec() with an
impossible length and hit BUG_ON(len).
Decoded from the original latest-net reproduction logs with
scripts/decode_stacktrace.sh:
RIP: __skb_to_sgvec()
[net/core/skbuff.c:5285 (discriminator 1)]
Call Trace:
skb_to_sgvec() [net/core/skbuff.c:5305]
rxgk_decrypt_skb() [net/rxrpc/rxgk_common.h:81]
rxgk_verify_response() [net/rxrpc/rxgk.c:1268]
rxrpc_process_connection()
[net/rxrpc/conn_event.c:266 net/rxrpc/conn_event.c:364
net/rxrpc/conn_event.c:386]
process_one_work() [kernel/workqueue.c:3281]
worker_thread()
[kernel/workqueue.c:3353 kernel/workqueue.c:3440]
kthread() [kernel/kthread.c:436]
ret_from_fork() [arch/x86/kernel/process.c:164]
Reject authenticator lengths that exceed the remaining packet payload. |
| A side-channel attack, which requires a physical presence to the TPM, can lead to extraction of an Elliptic Curve Diffie-Hellman (ECDH) key. |
| In the Linux kernel, the following vulnerability has been resolved:
net: nfc: nci: Fix parameter validation for packet data
Since commit 9c328f54741b ("net: nfc: nci: Add parameter validation for
packet data") communication with nci nfc chips is not working any more.
The mentioned commit tries to fix access of uninitialized data, but
failed to understand that in some cases the data packet is of variable
length and can therefore not be compared to the maximum packet length
given by the sizeof(struct). |
| In the Linux kernel, the following vulnerability has been resolved:
EFI/CPER: don't go past the ARM processor CPER record buffer
There's a logic inside GHES/CPER to detect if the section_length
is too small, but it doesn't detect if it is too big.
Currently, if the firmware receives an ARM processor CPER record
stating that a section length is big, kernel will blindly trust
section_length, producing a very long dump. For instance, a 67
bytes record with ERR_INFO_NUM set 46198 and section length
set to 854918320 would dump a lot of data going a way past the
firmware memory-mapped area.
Fix it by adding a logic to prevent it to go past the buffer
if ERR_INFO_NUM is too big, making it report instead:
[Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 1
[Hardware Error]: event severity: recoverable
[Hardware Error]: Error 0, type: recoverable
[Hardware Error]: section_type: ARM processor error
[Hardware Error]: MIDR: 0xff304b2f8476870a
[Hardware Error]: section length: 854918320, CPER size: 67
[Hardware Error]: section length is too big
[Hardware Error]: firmware-generated error record is incorrect
[Hardware Error]: ERR_INFO_NUM is 46198
[ rjw: Subject and changelog tweaks ] |
