| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
dm-stripe: fix a possible integer overflow
There's a possible integer overflow in stripe_io_hints if we have too
large chunk size. Test if the overflow happened, and if it did, don't set
limits->io_min and limits->io_opt; |
| A Use of Incorrect Byte Ordering
vulnerability
in the Routing Protocol Daemon (rpd) of Juniper Networks Junos OS on SRX300 Series allows an unauthenticated, network-based attacker to cause a Denial-of-Service (DoS).
When a BGP update is received over an established BGP session which contains a specific, valid, optional, transitive path attribute, rpd will crash and restart.
This issue affects eBGP and iBGP over IPv4 and IPv6.
This issue affects:
Junos OS:
* 22.1 versions from 22.1R1 before 22.2R3-S4,
* 22.3 versions before 22.3R3-S3,
* 22.4 versions before 22.4R3-S2,
* 23.2 versions before 23.2R2,
* 23.4 versions before 23.4R2. |
| Sandbox escape due to integer overflow in the Graphics component. This vulnerability affects Firefox < 147, Firefox ESR < 115.32, Firefox ESR < 140.7, Thunderbird < 147, and Thunderbird < 140.7. |
| ESF-IDF is the Espressif Internet of Things (IOT) Development Framework. An integer underflow vulnerability has been identified in the ESP-NOW protocol implementation within the ESP Wi-Fi component of versions 5.4.1, 5.3.3, 5.2.5, and 5.1.6 of the ESP-IDF framework. This issue stems from insufficient validation of user-supplied data length in the packet receive function. Under certain conditions, this may lead to out-of-bounds memory access and may allow arbitrary memory write operations. On systems without a memory protection scheme, this behavior could potentially be used to achieve remote code execution (RCE) on the target device. In versions 5.4.2, 5.3.4, 5.2.6, and 5.1.6, ESP-NOW has added more comprehensive validation logic on user-supplied data length during packet reception to prevent integer underflow caused by negative value calculations. For ESP-IDF v5.3 and earlier, a workaround can be applied by validating that the `data_len` parameter received in the RX callback (registered via `esp_now_register_recv_cb()`) is a positive value before further processing. For ESP-IDF v5.4 and later, no application-level workaround is available. Users are advised to upgrade to a patched version of ESP-IDF to take advantage of the built-in mitigation. |
| A vulnerability was found in libtiff due to multiple potential integer overflows in raw2tiff.c. This flaw allows remote attackers to cause a denial of service or possibly execute an arbitrary code via a crafted tiff image, which triggers a heap-based buffer overflow. |
| LibTIFF is vulnerable to an integer overflow. This flaw allows remote attackers to cause a denial of service (application crash) or possibly execute an arbitrary code via a crafted tiff image, which triggers a heap-based buffer overflow. |
| LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. From 1.6.26 to 1.6.53, there is an integer truncation in the libpng simplified write API functions png_write_image_16bit and png_write_image_8bit causes heap buffer over-read when the caller provides a negative row stride (for bottom-up image layouts) or a stride exceeding 65535 bytes. The bug was introduced in libpng 1.6.26 (October 2016) by casts added to silence compiler warnings on 16-bit systems. This vulnerability is fixed in 1.6.54. |
| A flaw was found in GIMP. An integer overflow vulnerability exists in the GIMP "Despeckle" plug-in. The issue occurs due to unchecked multiplication of image dimensions, such as width, height, and bytes-per-pixel (img_bpp), which can result in allocating insufficient memory and subsequently performing out-of-bounds writes. This issue could lead to heap corruption, a potential denial of service (DoS), or arbitrary code execution in certain scenarios. |
| GIMP PNM File Parsing Integer Overflow Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of GIMP. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file.
The specific flaw exists within the parsing of PNM files. The issue results from the lack of proper validation of user-supplied data, which can result in an integer overflow before allocating a buffer. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-28273. |
| In the Linux kernel, the following vulnerability has been resolved:
x86/MCE/AMD: Use an u64 for bank_map
Thee maximum number of MCA banks is 64 (MAX_NR_BANKS), see
a0bc32b3cacf ("x86/mce: Increase maximum number of banks to 64").
However, the bank_map which contains a bitfield of which banks to
initialize is of type unsigned int and that overflows when those bit
numbers are >= 32, leading to UBSAN complaining correctly:
UBSAN: shift-out-of-bounds in arch/x86/kernel/cpu/mce/amd.c:1365:38
shift exponent 32 is too large for 32-bit type 'int'
Change the bank_map to a u64 and use the proper BIT_ULL() macro when
modifying bits in there.
[ bp: Rewrite commit message. ] |
| In the Linux kernel, the following vulnerability has been resolved:
ext4: fix off-by-one errors in fast-commit block filling
Due to several different off-by-one errors, or perhaps due to a late
change in design that wasn't fully reflected in the code that was
actually merged, there are several very strange constraints on how
fast-commit blocks are filled with tlv entries:
- tlvs must start at least 10 bytes before the end of the block, even
though the minimum tlv length is 8. Otherwise, the replay code will
ignore them. (BUG: ext4_fc_reserve_space() could violate this
requirement if called with a len of blocksize - 9 or blocksize - 8.
Fortunately, this doesn't seem to happen currently.)
- tlvs must end at least 1 byte before the end of the block. Otherwise
the replay code will consider them to be invalid. This quirk
contributed to a bug (fixed by an earlier commit) where uninitialized
memory was being leaked to disk in the last byte of blocks.
Also, strangely these constraints don't apply to the replay code in
e2fsprogs, which will accept any tlvs in the blocks (with no bounds
checks at all, but that is a separate issue...).
Given that this all seems to be a bug, let's fix it by just filling
blocks with tlv entries in the natural way.
Note that old kernels will be unable to replay fast-commit journals
created by kernels that have this commit. |
| In Eclipse Paho Go MQTT v3.1 library (paho.mqtt.golang) versions <=1.5.0 UTF-8 encoded strings, passed into the library, may be incorrectly encoded if their length exceeds 65535 bytes. This may lead to unexpected content in packets sent to the server (for example, part of an MQTT topic may leak into the message body in a PUBLISH packet).
The issue arises because the length of the data passed in was converted from an int64/int32 (depending upon CPU) to an int16 without checks for overflows. The int16 length was then written, followed by the data (e.g. topic). This meant that when the data (e.g. topic) was over 65535 bytes then the amount of data written exceeds what the length field indicates. This could lead to a corrupt packet, or mean that the excess data leaks into another field (e.g. topic leaks into message body). |
| Off-by-one error vulnerability in the transmission component in Synology Replication Service before 1.0.12-0066, 1.2.2-0353 and 1.3.0-0423 and Synology Unified Controller (DSMUC) before 3.1.4-23079 allows remote attackers to execute arbitrary code, potentially leading to a broader impact across the system via unspecified vectors. |
| 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. |
| In the Linux kernel, the following vulnerability has been resolved:
modpost: fix off by one in is_executable_section()
The > comparison should be >= to prevent an out of bounds array
access. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/radeon: Fix integer overflow in radeon_cs_parser_init
The type of size is unsigned, if size is 0x40000000, there will be an
integer overflow, size will be zero after size *= sizeof(uint32_t),
will cause uninitialized memory to be referenced later |
| In the Linux kernel, the following vulnerability has been resolved:
media: atomisp: prevent integer overflow in sh_css_set_black_frame()
The "height" and "width" values come from the user so the "height * width"
multiplication can overflow. |
| iccDEV provides a set of libraries and tools for working with ICC color management profiles. Versions 2.3.1.1 and below have Out-of-bounds Read and Integer Underflow (Wrap or Wraparound) vulnerabilities in its CIccCalculatorFunc::SequenceNeedTempReset function. This issue is fixed in version 2.3.1.2. |
| iccDEV provides a set of libraries and tools for working with ICC color management profiles. Versions 2.3.1.1 and below are prone to have Undefined Behavior (UB) and Out of Memory errors. This issue is fixed in version 2.3.1.2. |
| OpenLDAP Lightning Memory-Mapped Database (LMDB) versions up to and including 0.9.14, prior to commit 8e1fda8, contain a heap buffer underflow in the readline() function of mdb_load. When processing malformed input containing an embedded NUL byte, an unsigned offset calculation can underflow and cause an out-of-bounds read of one byte before the allocated heap buffer. This can cause mdb_load to crash, leading to a limited denial-of-service condition. |
