Total
12867 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2023-48342 | 2 Google, Unisoc | 14 Android, S8000, Sc7731e and 11 more | 2025-06-20 | 4.4 Medium |
| In media service, there is a possible out of bounds write due to a missing bounds check. This could lead to local denial of service with System execution privileges needed | ||||
| CVE-2023-48340 | 2 Google, Unisoc | 14 Android, S8000, Sc7731e and 11 more | 2025-06-20 | 5.5 Medium |
| In video decoder, there is a possible out of bounds write due to improper input validation. This could lead to local denial of service with no additional execution privileges needed | ||||
| CVE-2023-6129 | 2 Openssl, Redhat | 2 Openssl, Enterprise Linux | 2025-06-20 | 6.5 Medium |
| Issue summary: The POLY1305 MAC (message authentication code) implementation contains a bug that might corrupt the internal state of applications running on PowerPC CPU based platforms if the CPU provides vector instructions. Impact summary: If an attacker can influence whether the POLY1305 MAC algorithm is used, the application state might be corrupted with various application dependent consequences. The POLY1305 MAC (message authentication code) implementation in OpenSSL for PowerPC CPUs restores the contents of vector registers in a different order than they are saved. Thus the contents of some of these vector registers are corrupted when returning to the caller. The vulnerable code is used only on newer PowerPC processors supporting the PowerISA 2.07 instructions. The consequences of this kind of internal application state corruption can be various - from no consequences, if the calling application does not depend on the contents of non-volatile XMM registers at all, to the worst consequences, where the attacker could get complete control of the application process. However unless the compiler uses the vector registers for storing pointers, the most likely consequence, if any, would be an incorrect result of some application dependent calculations or a crash leading to a denial of service. The POLY1305 MAC algorithm is most frequently used as part of the CHACHA20-POLY1305 AEAD (authenticated encryption with associated data) algorithm. The most common usage of this AEAD cipher is with TLS protocol versions 1.2 and 1.3. If this cipher is enabled on the server a malicious client can influence whether this AEAD cipher is used. This implies that TLS server applications using OpenSSL can be potentially impacted. However we are currently not aware of any concrete application that would be affected by this issue therefore we consider this a Low severity security issue. | ||||
| CVE-2023-51970 | 1 Tenda | 2 Ax1803, Ax1803 Firmware | 2025-06-20 | 9.8 Critical |
| Tenda AX1803 v1.0.0.1 contains a stack overflow via the iptv.stb.mode parameter in the function formSetIptv. | ||||
| CVE-2023-51969 | 1 Tenda | 2 Ax1803, Ax1803 Firmware | 2025-06-20 | 9.8 Critical |
| Tenda AX1803 v1.0.0.1 contains a stack overflow via the iptv.city.vlan parameter in the function getIptvInfo. | ||||
| CVE-2023-51967 | 1 Tenda | 2 Ax1803, Ax1803 Firmware | 2025-06-20 | 9.8 Critical |
| Tenda AX1803 v1.0.0.1 contains a stack overflow via the iptv.stb.port parameter in the function getIptvInfo. | ||||
| CVE-2023-51966 | 1 Tenda | 2 Ax1803, Ax1803 Firmware | 2025-06-20 | 9.8 Critical |
| Tenda AX1803 v1.0.0.1 contains a stack overflow via the adv.iptv.stballvlans parameter in the function setIptvInfo. | ||||
| CVE-2023-51965 | 1 Tenda | 2 Ax1803, Ax1803 Firmware | 2025-06-20 | 9.8 Critical |
| Tenda AX1803 v1.0.0.1 contains a stack overflow via the adv.iptv.stbpvid parameter in the function setIptvInfo. | ||||
| CVE-2023-51963 | 1 Tenda | 2 Ax1803, Ax1803 Firmware | 2025-06-20 | 9.8 Critical |
| Tenda AX1803 v1.0.0.1 contains a stack overflow via the iptv.city.vlan parameter in the function setIptvInfo. | ||||
| CVE-2023-51953 | 1 Tenda | 2 Ax1803, Ax1803 Firmware | 2025-06-20 | 9.8 Critical |
| Tenda AX1803 v1.0.0.1 contains a stack overflow via the iptv.stb.mode parameter in the function formSetIptv. | ||||
| CVE-2023-51952 | 1 Tenda | 2 Ax1803, Ax1803 Firmware | 2025-06-20 | 9.8 Critical |
| Tenda AX1803 v1.0.0.1 contains a stack overflow via the adv.iptv.stbpvid parameter in the function formSetIptv. | ||||
| CVE-2023-49236 | 1 Trendnet | 2 Tv-ip1314pi, Tv-ip1314pi Firmware | 2025-06-20 | 9.8 Critical |
| A stack-based buffer overflow was discovered on TRENDnet TV-IP1314PI 5.5.3 200714 devices, leading to arbitrary command execution. This occurs because of lack of length validation during an sscanf of a user-entered scale field in the RTSP playback function of davinci. | ||||
| CVE-2023-42869 | 1 Apple | 3 Ipados, Iphone Os, Macos | 2025-06-20 | 7.5 High |
| Multiple memory corruption issues were addressed with improved input validation. This issue is fixed in macOS Ventura 13.4, iOS 16.5 and iPadOS 16.5. Multiple issues in libxml2. | ||||
| CVE-2024-46919 | 1 Samsung | 16 Exynos 1080, Exynos 1080 Firmware, Exynos 1280 and 13 more | 2025-06-20 | 5.3 Medium |
| An issue was discovered in Samsung Mobile Processor Exynos 9820, 9825, 980, 990, 850, 1080, 2100, and 1280. Lack of a length check leads to a stack out-of-bounds write at loadOutputBuffers. | ||||
| CVE-2024-46920 | 1 Samsung | 16 Exynos 1080, Exynos 1080 Firmware, Exynos 1280 and 13 more | 2025-06-20 | 6.5 Medium |
| An issue was discovered in Samsung Mobile Processor Exynos 9820, 9825, 980, 990, 850, 1080, 2100, and 1280. Lack of a length check leads to a stack out-of-bounds write at loadInputBuffers. | ||||
| CVE-2025-6110 | 1 Tenda | 2 Fh1201, Fh1201 Firmware | 2025-06-20 | 8.8 High |
| A vulnerability classified as critical has been found in Tenda FH1201 1.2.0.14(408). This affects an unknown part of the file /goform/SafeMacFilter. The manipulation of the argument page leads to stack-based buffer overflow. It is possible to initiate the attack remotely. The exploit has been disclosed to the public and may be used. | ||||
| CVE-2024-45025 | 1 Linux | 1 Linux Kernel | 2025-06-19 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: fix bitmap corruption on close_range() with CLOSE_RANGE_UNSHARE copy_fd_bitmaps(new, old, count) is expected to copy the first count/BITS_PER_LONG bits from old->full_fds_bits[] and fill the rest with zeroes. What it does is copying enough words (BITS_TO_LONGS(count/BITS_PER_LONG)), then memsets the rest. That works fine, *if* all bits past the cutoff point are clear. Otherwise we are risking garbage from the last word we'd copied. For most of the callers that is true - expand_fdtable() has count equal to old->max_fds, so there's no open descriptors past count, let alone fully occupied words in ->open_fds[], which is what bits in ->full_fds_bits[] correspond to. The other caller (dup_fd()) passes sane_fdtable_size(old_fdt, max_fds), which is the smallest multiple of BITS_PER_LONG that covers all opened descriptors below max_fds. In the common case (copying on fork()) max_fds is ~0U, so all opened descriptors will be below it and we are fine, by the same reasons why the call in expand_fdtable() is safe. Unfortunately, there is a case where max_fds is less than that and where we might, indeed, end up with junk in ->full_fds_bits[] - close_range(from, to, CLOSE_RANGE_UNSHARE) with * descriptor table being currently shared * 'to' being above the current capacity of descriptor table * 'from' being just under some chunk of opened descriptors. In that case we end up with observably wrong behaviour - e.g. spawn a child with CLONE_FILES, get all descriptors in range 0..127 open, then close_range(64, ~0U, CLOSE_RANGE_UNSHARE) and watch dup(0) ending up with descriptor #128, despite #64 being observably not open. The minimally invasive fix would be to deal with that in dup_fd(). If this proves to add measurable overhead, we can go that way, but let's try to fix copy_fd_bitmaps() first. * new helper: bitmap_copy_and_expand(to, from, bits_to_copy, size). * make copy_fd_bitmaps() take the bitmap size in words, rather than bits; it's 'count' argument is always a multiple of BITS_PER_LONG, so we are not losing any information, and that way we can use the same helper for all three bitmaps - compiler will see that count is a multiple of BITS_PER_LONG for the large ones, so it'll generate plain memcpy()+memset(). Reproducer added to tools/testing/selftests/core/close_range_test.c | ||||
| CVE-2024-36702 | 1 Mz-automation | 1 Libiec61850 | 2025-06-18 | 7.4 High |
| libiec61850 v1.5 was discovered to contain a heap overflow via the BerEncoder_encodeLength function at /asn1/ber_encoder.c. | ||||
| CVE-2024-22086 | 1 Hayyp | 1 Cherry | 2025-06-18 | 9.8 Critical |
| handle_request in http.c in cherry through 4b877df has an sscanf stack-based buffer overflow via a long URI, leading to remote code execution. | ||||
| CVE-2024-0223 | 2 Fedoraproject, Google | 2 Fedora, Chrome | 2025-06-18 | 8.8 High |
| Heap buffer overflow in ANGLE in Google Chrome prior to 120.0.6099.199 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High) | ||||