| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| NVIDIA GPU Display Driver for Windows and Linux contains a vulnerability in the kernel mode layer where an attacker could cause an improper validation of an array index. A successful exploit of this vulnerability might lead to code execution, denial of service, escalation of privileges, information disclosure, and data tampering. |
| NVIDIA GPU Display Driver for Windows and Linux contains a vulnerability in the kernel mode layer, where a user could cause an out-of-bounds array access. A successful exploit of this vulnerability might lead to code execution, denial of service, escalation of privileges, information disclosure, and data tampering. |
| NVIDIA GPU Display Driver for Windows and Linux contains a vulnerability in the kernel mode layer where an attacker could cause an improper validation of an array index. A successful exploit of this vulnerability might lead to code execution, denial of service, escalation of privileges, information disclosure, and data tampering. |
| IBM PowerVM Hypervisor FW1120.00 through FW1120.01, FW1110.00 through FW1110.31, FW1060.00 through FW1060.81, and FW950.00 through FW950.H3 is affected by a vulnerability in the RTAS firmware-to-OS interface. An attacker with administrator-level (root) access to a logical partition can send a specially crafted request to partition firmware, causing the partition to crash and become unavailable. Other partitions on the same managed system are not affected. |
| Integer Overflow, Improper Validation of Array Index, Uncontrolled Recursion and Memory Allocation with Excessive Size Value in the Go implementation of Apache PLC4X (PLC4Go) allow a malicious device, or an attacker able to inject network traffic, to crash or exhaust the memory of the client application,
causing a denial of service.
The individual defects are:
- Generated parsers pre-allocate arrays with the element count claimed on the wire (0.13.0 through 0.13.1).
- Transport read helpers allocate buffers of the size claimed on the wire without an upper bound.
- ADS and KNXnet/IP response handling indexes into received data without checking its length, causing a panic.
- ADS and EIP frame-length handling accepts, or arithmetically wraps to, a length of zero, breaking message framing.
- Recursive protocol types are parsed without a nesting-depth limit. The same defect in the Java implementation is covered by CVE-2026-102509 https://cveprocess.apache.org/cve5/CVE-2026-102509 .
Additionally, length and position arithmetic in generated serializers was performed in 16-bit integers. If an application forwards attacker-influenced payloads larger than 8 KB, the length field wraps, and the remainder of the payload may be interpreted by the receiving device (for example, an ADS PLC) as
additional, independent protocol messages.
This issue affects Apache PLC4X: from 0.11.0 before 1.0.0. PLC4Go is consumed as the Go module github.com/apache/plc4x/plc4go; versions refer to the corresponding Apache PLC4X releases.
Users are recommended to upgrade to version 1.0.0, which fixes the issue. |
| vLLM before 0.29.0 accepts user-controlled stop_token_ids on the OpenAI-compatible POST /v1/completions and POST /v1/chat/completions endpoints but validates only that the values are integers, not that each token id is within the model vocabulary/logits range. When min_tokens > 0, the stop token ids are used as logits indices to suppress stop tokens, so an out-of-range id reaches a CUDA indexing operation (index_put_) and triggers a device-side assertion. An authenticated API user can send a single malformed completion request that returns 500 Internal Server Error and puts EngineCore into a fatal state, causing subsequent requests to fail until the service is restarted (denial of service). |
| Improper Verification of Source of a Communication Channel in the ADS discovery of the Go implementation of Apache PLC4X (PLC4Go) allows an attacker able to send UDP datagrams to the discovering host to redirect subsequent connections to an arbitrary, attacker-chosen address. The discovery result's connection
address was derived from the AmsNetId claimed in the response body rather than from the datagram's actual source address. One spoofed discovery response can therefore insert an inventory entry pointing at any host, including hosts outside the local network, and an application that connects to discovered devices
will open its ADS session, including any configured route credentials, to that host.
Additionally, discovery listeners in both implementations can be disabled by a single malformed datagram:
- In PLC4Go ADS discovery, a short version block causes a panic that ends the listener for the rest of the discovery call, so legitimate devices answering afterwards are not reported.
- In PLC4J, the ADS and EtherNet/IP discoverers stop on an unhandled exception from a malformed response.
- The PLC4J Modbus discoverer can be made to spin indefinitely, consuming a CPU core, by a scanned host that sends a partial response.
Exploitation requires the application to invoke the discovery API, which is opt-in, and for the connection redirect, to act on the discovered items.
This issue affects Apache PLC4X: PLC4Go from 0.11.0 before 1.0.0; PLC4J ADS and Modbus drivers from 0.10.0 before 1.0.0; PLC4J EtherNet/IP driver from 0.11.0 before 1.0.0. PLC4Go is consumed as the Go module github.com/apache/plc4x/plc4go; versions refer to the corresponding Apache PLC4X releases.
Users are recommended to upgrade to version 1.0.0, which fixes the issue. Version 1.0.0 derives the connection address from the datagram's source address and logs a warning when the claimed AmsNetId disagrees with it. |
| Russh is a Rust SSH client and server library. Prior to 0.63.1, a connection configured to permit mac=none can negotiate it with a MAC-requiring CTR or CBC block cipher because the selection logic validates needs_mac() only when MAC selection fails. A remote peer can then send a packet with a decrypted length of zero, causing russh/src/cipher/mod.rs to shrink the previously read block before indexing buffer.buffer[16..], which panics and terminates the connection task. This issue is fixed in version 0.63.1. |
| OpenImageIO is a toolset for reading, writing, and manipulating image files of any image file format relevant to VFX / animation. Prior to 3.0.21.0, 3.1.16.0, and 3.2.0.3-beta1, An indexed psd with transparency metadata creates fewer stored channel_buffers than the spec.nchannels value advertised by the rawcolor path. when oiio:rawcolor or psd:rawdata is enabled, psdinput::read_native_scanline() passes spec.nchannels to psdinput::interleave_row(), which indexes beyond channel_buffers, resulting in a heap out-of-bounds read and process crash. The affected implementation is identified by src/psd.imageio/psdinput.cpp, PSDInput::read_native_scanline(), PSDInput::interleave_row(), oiio:RawColor, psd:RawData, channel_buffers, and spec.nchannels, which define the relevant source path, functions, state, and trigger. This issue is fixed in versions 3.0.21.0, 3.1.16.0, and 3.2.0.3-beta1. |
| OpenImageIO is a toolset for reading, writing, and manipulating image files of any image file format relevant to VFX / animation. Prior to 3.0.21.0, 3.1.16.0, and 3.2.0.3-beta1, A crafted psd with an invalid color_mode bypasses normal validation when oiio:rawcolor or psd:rawdata is enabled. psdinput::setup() then uses the attacker-controlled value to index fixed color-mode tables, causing a global out-of-bounds read and potentially a bogus allocation, resulting in denial of service. The affected implementation is identified by src/psd.imageio/psdinput.cpp, PSDInput::validate_header(), PSDInput::setup(), oiio:RawColor, psd:RawData, color_mode, and mode_channel_count, which define the relevant source path, functions, state, and trigger. This issue is fixed in versions 3.0.21.0, 3.1.16.0, and 3.2.0.3-beta1. |
| Wire provides gRPC and protocol buffers for Android, Kotlin, Swift, and Java. Prior to 6.4.1 and 7.0.0-alpha04, Wire's Swift runtime ProtoReader.skipGroup(expectedEndTag:unknownFieldsWriter:) accepts a negative length for a LENGTH_DELIMITED field inside an unknown START_GROUP field. ProtoReader.readData() forwards the negative count to ReadBuffer.readData(count:), whose upper-bound-only check permits the value to reach Foundation Data(bytes:count:) and trigger an unrecoverable process trap instead of a catchable ProtoDecoder.Error. Any Swift process decoding untrusted protobuf bytes can be crashed without authentication, user interaction, or knowledge of the target schema. This issue is fixed in versions 6.4.1 and 7.0.0-alpha04. |
| Contrast through 1.20.0 contains a panic vulnerability in the transit-engine endpoint's ciphertextContainer.UnmarshalJSON function that fails to validate decoded ciphertext length before slicing. An authenticated workload with a valid mesh certificate can trigger a runtime panic by submitting a short base64-encoded ciphertext, causing log spam and request failures without crashing the process. |
| In the Linux kernel, the following vulnerability has been resolved:
smb: client: reject out-of-bounds DataOffset in CIFSSMBRead()
The SMB1 synchronous read helper CIFSSMBRead() validates the server's
DataLength against CIFSMaxBufSize and the caller's count, but never
validates DataOffset. The copy source is formed as
&pSMBr->hdr.Protocol + le16_to_cpu(pSMBr->DataOffset)
and memcpy()'d for DataLength bytes with no check that the
[DataOffset, DataOffset + DataLength) range lies within the response
actually received from the server.
A malicious or compromised SMB1 server can return a response carrying
an in-range DataLength and a large DataOffset, driving the source
pointer past the end of the response buffer. The memcpy() then copies
adjacent kernel heap into the caller's read buffer (information
disclosure), or reads unmapped memory and oopses (denial of service).
SMB1 is not negotiated by default; reaching this code requires an
explicit vers=1.0 mount.
Both DataOffset and the received response length recorded in
rsp_iov.iov_len are relative to the start of the SMB header, so reject
the response unless DataOffset + DataLength fits within that length,
using overflow-safe arithmetic, before forming the source pointer.
The response length has been validated by the previous patch, so the
DataOffset and DataLength fields can be read safely here.
While here, make data_length unsigned. It holds a length derived from
unsigned on-the-wire fields and is only ever compared against unsigned
quantities; print it with %u accordingly, and add __func__ to the
cifs_dbg() calls in this function. |
| In the Linux kernel, the following vulnerability has been resolved:
cxl/region: Validate partition index before array access
construct_region() reads cxled->part and uses it to index
cxlds->part[] without checking for a negative value. If the
partition was never resolved, part remains at its initial value
of -1, causing an out-of-bounds array access.
Add a guard to return -EBUSY when part is negative.
The check was dropped during a merge. |
| Missing bounds validation for operator could allow out of range operator-code lookup during model loading
Affected version is prior to commit 1.30.0. |
| NVIDIA DALI contains a vulnerability in a component where an attacker could cause an improper index validation. A successful exploit of this vulnerability might lead to code execution, data tampering, denial of service, and information disclosure. |
| alsa-lib through 1.2.16.1 contains a denial of service vulnerability in the multi PCM plugin that fails to validate sparse binding indices before array access. Attackers can supply a malicious ALSA configuration file with sparse bindings to trigger an out-of-bounds array read and assertion failure, causing the application to abort. |
| A heap-based buffer overflow vulnerability exists in the vtkDICOMItem::FindDataElementOrInsert functionality of vtk-dicom (version(s): 9.5.2). A specially crafted DICOM file can lead to heap-based memory corruption. An attacker can provide a malicious file to trigger this vulnerability. |
| vLLM versions before 0.28.0 fail to validate the lower bound of token IDs in the /v1/embeddings and /pooling endpoints, allowing unauthenticated attackers to crash the engine by submitting negative token IDs. A single request with a negative token ID triggers a CUDA device-side assertion that poisons the GPU context, causing all subsequent requests to fail until the process restarts. |
| vLLM before 0.29.0 validates allowed_token_ids against tokenizer length instead of model output logits width in SamplingParams._validate_allowed_token_ids(). Attackers can supply token IDs above the output vocabulary that pass validation, causing LogitBiasState to corrupt GPU logits state and allow concurrent requests to sample tokens outside their allowlists. |
