| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In libavif before 1.3.0, avifImageRGBToYUV in reformat.c has integer overflows in multiplications involving rgbRowBytes, yRowBytes, uRowBytes, and vRowBytes. |
| In libavif before 1.3.0, makeRoom in stream.c has an integer overflow and resultant buffer overflow in stream->offset+size. |
| Asterisk is an open-source private branch exchange (PBX). Prior to versions 18.26.2, 20.14.1, 21.9.1, and 22.4.1 of Asterisk and versions 18.9-cert14 and 20.7-cert5 of certified-asterisk, SIP requests of the type MESSAGE (RFC 3428) authentication do not get proper alignment. An authenticated attacker can spoof any user identity to send spam messages to the user with their authorization token. Abuse of this security issue allows authenticated attackers to send fake chat messages can be spoofed to appear to come from trusted entities. Even administrators who follow Security best practices and Security Considerations can be impacted. Therefore, abuse can lead to spam and enable social engineering, phishing and similar attacks. Versions 18.26.2, 20.14.1, 21.9.1, and 22.4.1 of Asterisk and versions 18.9-cert14 and 20.7-cert5 of certified-asterisk fix the issue. |
| An out-of-bounds read vulnerability exists in the EMF functionality of PDF-XChange Co. Ltd PDF-XChange Editor 10.6.0.396. By using a specially crafted EMF file, an attacker could exploit this vulnerability to perform an out-of-bounds read, potentially leading to the disclosure of sensitive information. |
| Improper Handling of Case Sensitivity vulnerability in Apache Tomcat's GCI servlet allows security constraint bypass of security constraints that apply to the pathInfo component of a URI mapped to the CGI servlet.
This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.6, from 10.1.0-M1 through 10.1.40, from 9.0.0.M1 through 9.0.104.
The following versions were EOL at the time the CVE was created but are
known to be affected: 8.5.0 though 8.5.100. Other, older, EOL versions
may also be affected.
Users are recommended to upgrade to version 11.0.7, 10.1.41 or 9.0.105, which fixes the issue. |
| In LibRaw before 0.21.4, tag 0x412 processing in phase_one_correct in decoders/load_mfbacks.cpp does not enforce minimum w0 and w1 values. |
| In LibRaw before 0.21.4, phase_one_correct in decoders/load_mfbacks.cpp allows out-of-buffer access because split_col and split_row values are not checked in 0x041f tag processing. |
| In LibRaw before 0.21.4, phase_one_correct in decoders/load_mfbacks.cpp has out-of-bounds reads for tag 0x412 processing, related to large w0 or w1 values or the frac and mult calculations. |
| In LibRaw before 0.21.4, metadata/tiff.cpp has an out-of-bounds read in the Fujifilm 0xf00c tag parser. |
| An out-of-bounds read was addressed with improved bounds checking. This issue is fixed in macOS Sonoma 14.7.7, macOS Sequoia 15.6, macOS Ventura 13.7.7. An app may be able to cause unexpected system termination. |
| An out-of-bounds read was addressed with improved input validation. This issue is fixed in macOS Sequoia 15.6, macOS Ventura 13.7.7, macOS Sonoma 14.7.7. Processing a maliciously crafted file may lead to unexpected app termination. |
| An out-of-bounds access issue was addressed with improved bounds checking. This issue is fixed in macOS Sequoia 15.6, macOS Sonoma 14.7.7, macOS Ventura 13.7.7. Processing a maliciously crafted file may lead to unexpected app termination. |
| An out-of-bounds read was addressed with improved input validation. This issue is fixed in watchOS 11.6, iOS 18.6 and iPadOS 18.6, iPadOS 17.7.9, tvOS 18.6, macOS Sequoia 15.6, macOS Sonoma 14.7.7, visionOS 2.6. Processing a maliciously crafted image may result in disclosure of process memory. |
| An out-of-bounds access issue was addressed with improved bounds checking. This issue is fixed in macOS Sequoia 15.6, iOS 18.6 and iPadOS 18.6, visionOS 2.6, tvOS 18.6. Processing a maliciously crafted media file may lead to unexpected app termination or corrupt process memory. |
| An out-of-bounds read was addressed with improved input validation. This issue is fixed in macOS Sequoia 15.6. Processing a maliciously crafted USD file may disclose memory contents. |
| The issue was addressed with improved memory handling. This issue is fixed in Safari 18.6, watchOS 11.6, iOS 18.6 and iPadOS 18.6, tvOS 18.6, macOS Sequoia 15.6, visionOS 2.6. Processing maliciously crafted web content may lead to an unexpected Safari crash. |
| The issue was addressed with improved memory handling. This issue is fixed in Safari 18.6, macOS Sequoia 15.6, iOS 18.6 and iPadOS 18.6, tvOS 18.6, watchOS 11.6, visionOS 2.6. Processing maliciously crafted web content may lead to an unexpected Safari crash. |
| The issue was addressed with improved memory handling. This issue is fixed in watchOS 11.6, iOS 18.6 and iPadOS 18.6, tvOS 18.6, macOS Sequoia 15.6, macOS Sonoma 14.7.7, visionOS 2.6, macOS Ventura 13.7.7. Parsing a file may lead to an unexpected app termination. |
| Memory safety bugs present in Firefox 136, Thunderbird 136, Firefox ESR 128.8, and Thunderbird 128.8. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox < 137, Firefox ESR < 128.9, Thunderbird < 137, and Thunderbird < 128.9. |
| In the Linux kernel, the following vulnerability has been resolved:
jfs: fix slab-out-of-bounds read in ea_get()
During the "size_check" label in ea_get(), the code checks if the extended
attribute list (xattr) size matches ea_size. If not, it logs
"ea_get: invalid extended attribute" and calls print_hex_dump().
Here, EALIST_SIZE(ea_buf->xattr) returns 4110417968, which exceeds
INT_MAX (2,147,483,647). Then ea_size is clamped:
int size = clamp_t(int, ea_size, 0, EALIST_SIZE(ea_buf->xattr));
Although clamp_t aims to bound ea_size between 0 and 4110417968, the upper
limit is treated as an int, causing an overflow above 2^31 - 1. This leads
"size" to wrap around and become negative (-184549328).
The "size" is then passed to print_hex_dump() (called "len" in
print_hex_dump()), it is passed as type size_t (an unsigned
type), this is then stored inside a variable called
"int remaining", which is then assigned to "int linelen" which
is then passed to hex_dump_to_buffer(). In print_hex_dump()
the for loop, iterates through 0 to len-1, where len is
18446744073525002176, calling hex_dump_to_buffer()
on each iteration:
for (i = 0; i < len; i += rowsize) {
linelen = min(remaining, rowsize);
remaining -= rowsize;
hex_dump_to_buffer(ptr + i, linelen, rowsize, groupsize,
linebuf, sizeof(linebuf), ascii);
...
}
The expected stopping condition (i < len) is effectively broken
since len is corrupted and very large. This eventually leads to
the "ptr+i" being passed to hex_dump_to_buffer() to get closer
to the end of the actual bounds of "ptr", eventually an out of
bounds access is done in hex_dump_to_buffer() in the following
for loop:
for (j = 0; j < len; j++) {
if (linebuflen < lx + 2)
goto overflow2;
ch = ptr[j];
...
}
To fix this we should validate "EALIST_SIZE(ea_buf->xattr)"
before it is utilised. |
