| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Out-of-bounds write in the firmware for the Intel(R) AMT and Intel(R) Standard Manageability within Ring 3: User Applications may allow a denial of service. Network adversary with an unauthenticated user combined with a low complexity attack may enable denial of service. This result may potentially occur via network access when attack requirements are not present without special internal knowledge and requires no user interaction. The potential vulnerability may impact the confidentiality (none), integrity (none) and availability (high) of the vulnerable system, resulting in subsequent system confidentiality (none), integrity (none) and availability (low) impacts. |
| Software installed and run as a non-privileged user may conduct improper GPU system calls resulting in platform instability and reboots. |
| Zenitel TCIV-3+ is vulnerable to an out-of-bounds write
vulnerability, which could allow a remote attacker to crash the device. |
| An out-of-bounds write in VirtIO network device emulation in BitVisor from commit 108df6 (2020-05-20) to commit 480907 (2025-07-06) allows local attackers to cause a denial of service (host hypervisor crash) via a crafted PCI configuration space access. Given it's a heap overflow in a privileged hypervisor context, exploitation may enable arbitrary code execution or guest-to-host privilege escalation. |
| When decoding an OpenEXR file that uses DWAA or DWAB compression, there's an implicit assumption that all image channels have the same pixel type (and size), and that if there are four channels, the first four are "B", "G", "R" and "A". The channel parsing code can be found in decode_header. The buffer td->uncompressed_data is allocated in decode_block based on the xsize, ysize and computed current_channel_offset.
The function dwa_uncompress then assumes at [5] that if there are 4 channels, these are "B", "G", "R" and "A", and in the calculations at [6] and [7] that all channels are of the same type, which matches the type of the main color channels.
If we set the main color channels to a 4-byte type and add duplicate or unknown channels of the 2-byte EXR_HALF type, then the addition at [7] will increment the pointer by 4-bytes * xsize * nb_channels, which will exceed the allocated buffer.
We recommend upgrading to version 8.0 or beyond. |
| When decoding an OpenEXR file that uses DWAA or DWAB compression, there's an implicit assumption that the height and width are divisible by 8.
If the height or width of the image is not divisible by 8, the copy loops at [0] and [1] will continue to write until the next multiple of 8.
The buffer td->uncompressed_data is allocated in decode_block based on the precise height and width of the image, so the "rounded-up" multiple of 8 in the copy loop can exceed the buffer bounds, and the write block starting at [2] can corrupt following heap memory.
We recommend upgrading to version 8.0 or beyond. |
| When decoding an OpenEXR file that uses DWAA or DWAB compression, the specified raw length of run-length-encoded data is not checked when using it to calculate the output data.
We read rle_raw_size from the input file at [0], we decompress and decode into the buffer td->rle_raw_data of size rle_raw_size at [1], and then at [2] we will access entries in this buffer up to (td->xsize - 1) * (td->ysize - 1) + rle_raw_size / 2, which may exceed rle_raw_size.
We recommend upgrading to version 8.0 or beyond. |
| Malicious software running in a guest VM can exploit the buffer overflow to achieve code execution on the host in the bhyve userspace process, which typically runs as root. Note that bhyve runs in a Capsicum sandbox, so malicious code is constrained by the capabilities available to the bhyve process. |
| In the Mullvad VPN client 2024.6 (Desktop), 2024.8 (iOS), and 2024.8-beta1 (Android), the exception-handling alternate stack can be exhausted, leading to heap-based out-of-bounds writes in enable() in exception_logging/unix.rs, aka MLLVD-CR-24-01. NOTE: achieving code execution is considered non-trivial. |
| The L2CAP receive data buffer for L2CAP packets is restricted to packet sizes smaller than the maximum supported packet size. Receiving a packet that exceeds the restricted buffer length may cause a crash. A hard reset is required to recover the crashed device. |
| Due to an unchecked buffer length, a specially crafted L2CAP packet can cause a buffer overflow. This buffer overflow triggers an assert, which results in a temporary denial of service.
If a watchdog timer is not enabled, a hard reset is required to recover the device. |
| Out-of-bounds Write vulnerability was discovered in Open Design Alliance Drawings SDK before 2025.10. Reading crafted DWF file and missing proper checks on received SectionIterator data can trigger an unhandled exception. This can allow attackers to cause a crash, potentially enabling a denial-of-service attack (Crash, Exit, or Restart) or possible code execution. |
| When decoding a frame for a SANM file (ANIM v0 variant), the decoded data can be larger than the buffer allocated for it.
Frames encoded with codec 48 can specify their resolution (width x height). A buffer of appropriate size is allocated depending on the resolution.
This codec can encode the frame contents using a run-length encoding algorithm. There are no checks that the decoded frame fits in the allocated buffer, leading to a heap-buffer-overflow.
process_frame_obj initializes the buffers based on the frame resolution:
We recommend upgrading to version 8.0 or beyond. |
| When parsing the header for a DHAV file, there's an integer underflow in offset calculation that leads to reading the duration from before the start of the allocated buffer.
If we load a DHAV file that is larger than MAX_DURATION_BUFFER_SIZE bytes (0x100000) for example 0x101000 bytes, then at [0] we have size = 0x101000. At [1] we have end_buffer_size = 0x100000, and at [2] we have end_buffer_pos = 0x1000.
The loop then scans backwards through the buffer looking for the dhav tag; when it is found, we'll calculate end_pos based on a 32-bit offset read from the buffer.
There is subsequently a check [3] that end_pos is within the section of the file that has been copied into end_buffer, but it only correctly handles the cases where end_pos is before the start of the file or after the section copied into end_buffer, and not the case where end_pos is within the the file, but before the section copied into end_buffer. If we provide such an offset, (end_pos - end_buffer_pos) can underflow, resulting in the subsequent access at [4] occurring before the beginning of the allocation.
We recommend upgrading to version 8.0 or beyond. |
| When calculating the content path in handling of MPEG-DASH manifests, there's an out-of-bounds NUL-byte write one byte past the end of the buffer.When we call xmlNodeGetContent below [0], it returns a buffer precisely allocated to match the string length, using strdup internally. If this buffer is not an empty string, it is assigned to root_url at [1].If the last (non-NUL) byte in this buffer is not '/' then we append '/' in-place at [2]. This will write two bytes into the buffer, starting at the last valid byte in the buffer, writing the NUL byte beyond the end of the allocated buffer.
We recommend upgrading to version 8.0 or beyond. |
| Out-of-bounds write vulnerability exists in Ricoh MFPs and printers. If a remote attacker sends a specially crafted request to the affected products, the products may be able to cause a denial-of-service (DoS) condition and/or user's data may be destroyed. |
| Factorio before 1.1.101 allows a crafted server to execute arbitrary code on clients via a custom map that leverages the ability of certain Lua base module functions to execute bytecode and generate fake objects. |
| Out-of-bounds write in some Intel(R) Graphics Drivers may allow an authenticated user to potentially enable escalation of privilege via local access. |
| ZKsync Era is a layer 2 rollup that uses zero-knowledge proofs to scale Ethereum. There is possible invalid stack access due to the addresses used to access the stack not properly being converted to cells. This issue has been patched in version 1.5.0. |
| An issue was discovered in Dolby UDC 4.5 through 4.13. A crash of the DD+ decoder process can occur when a malformed DD+ bitstream is processed. When Evolution data is processed by evo_priv.c from the DD+ bitstream, the decoder writes that data into a buffer. The length calculation for a write can overflow due to an integer wraparound. This can lead to the allocated buffer being too small, and the out-of-bounds check of the subsequent write to be ineffective, leading to an out-of-bounds write. |
