Total
34 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2025-62786 | 1 Wazuh | 1 Wazuh | 2025-11-03 | 8.1 High |
| Wazuh is a free and open source platform used for threat prevention, detection, and response. A heap-based out-of-bounds WRITE occurs in decode_win_permissions, resulting in writing a NULL byte 2 bytes before the start of the buffer allocated to decoded_it. A compromised agent can potentially leverage this issue to perform remote code execution, by sending a specially crafted message to the wazuh manager. An attacker who is able to craft and send an agent message to the wazuh manager can leverage this issue to potentially achieve remote code execution on the wazuh manager (the exploitability of this vulnerability depends on the specifics of the respective heap allocator). This vulnerability is fixed in 4.10.2. | ||||
| CVE-2023-49991 | 1 Espeak-ng | 1 Espeak-ng | 2025-11-03 | 5.3 Medium |
| Espeak-ng 1.52-dev was discovered to contain a Stack Buffer Underflow via the function CountVowelPosition at synthdata.c. | ||||
| CVE-2021-38578 | 3 Insyde, Redhat, Tianocore | 3 Kernel, Enterprise Linux, Edk2 | 2025-11-03 | 7.4 High |
| Existing CommBuffer checks in SmmEntryPoint will not catch underflow when computing BufferSize. | ||||
| CVE-2021-38575 | 3 Insyde, Redhat, Tianocore | 5 Kernel, Enterprise Linux, Rhel Eus and 2 more | 2025-11-03 | 8.1 High |
| NetworkPkg/IScsiDxe has remotely exploitable buffer overflows. | ||||
| CVE-2021-36064 | 2 Adobe, Debian | 2 Xmp Toolkit Software Development Kit, Debian Linux | 2025-11-03 | 7.8 High |
| XMP Toolkit version 2020.1 (and earlier) is affected by a Buffer Underflow vulnerability which could result in arbitrary code execution in the context of the current user. Exploitation of this issue requires user interaction in that a victim must open a malicious file. | ||||
| CVE-2025-53101 | 1 Imagemagick | 1 Imagemagick | 2025-11-03 | 7.4 High |
| ImageMagick is free and open-source software used for editing and manipulating digital images. In versions prior to 7.1.2-0 and 6.9.13-26, in ImageMagick's `magick mogrify` command, specifying multiple consecutive `%d` format specifiers in a filename template causes internal pointer arithmetic to generate an address below the beginning of the stack buffer, resulting in a stack overflow through `vsnprintf()`. Versions 7.1.2-0 and 6.9.13-26 fix the issue. | ||||
| CVE-2025-27439 | 1 Zoom | 6 Meeting Software Development Kit, Rooms, Rooms Controller and 3 more | 2025-10-22 | 8.5 High |
| Buffer underflow in some Zoom Workplace Apps may allow an authenticated user to conduct an escalation of privilege via network access. | ||||
| CVE-2025-27440 | 1 Zoom | 6 Meeting Software Development Kit, Rooms, Rooms Controller and 3 more | 2025-10-22 | 8.5 High |
| Heap overflow in some Zoom Workplace Apps may allow an authenticated user to conduct an escalation of privilege via network access. | ||||
| CVE-2015-2426 | 1 Microsoft | 9 Windows 10, Windows 7, Windows 8 and 6 more | 2025-10-22 | 8.8 High |
| Buffer underflow in atmfd.dll in the Windows Adobe Type Manager Library in Microsoft Windows Vista SP2, Windows Server 2008 SP2 and R2 SP1, Windows 7 SP1, Windows 8, Windows 8.1, Windows Server 2012 Gold and R2, and Windows RT Gold and 8.1 allows remote attackers to execute arbitrary code via a crafted OpenType font, aka "OpenType Font Driver Vulnerability." | ||||
| CVE-2024-46718 | 1 Linux | 1 Linux Kernel | 2025-10-08 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: drm/xe: Don't overmap identity VRAM mapping Overmapping the identity VRAM mapping is triggering hardware bugs on certain platforms. Use 2M pages for the last unaligned (to 1G) VRAM chunk. v2: - Always use 2M pages for last chunk (Fei Yang) - break loop when 2M pages are used - Add assert for usable_size being 2M aligned v3: - Fix checkpatch | ||||
| CVE-2025-4373 | 1 Redhat | 8 Enterprise Linux, Insights Proxy, Openshift Distributed Tracing and 5 more | 2025-10-08 | 4.8 Medium |
| A flaw was found in GLib, which is vulnerable to an integer overflow in the g_string_insert_unichar() function. When the position at which to insert the character is large, the position will overflow, leading to a buffer underwrite. | ||||
| CVE-2025-61690 | 1 Keyence | 1 Kv Studio | 2025-10-03 | 7.8 High |
| KV STUDIO versions 12.23 and prior contain a buffer underflow vulnerability. If the product uses a specially crafted file, arbitrary code may be executed on the affected product. | ||||
| CVE-2024-53158 | 1 Linux | 1 Linux Kernel | 2025-10-01 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: soc: qcom: geni-se: fix array underflow in geni_se_clk_tbl_get() This loop is supposed to break if the frequency returned from clk_round_rate() is the same as on the previous iteration. However, that check doesn't make sense on the first iteration through the loop. It leads to reading before the start of these->clk_perf_tbl[] array. | ||||
| CVE-2024-56771 | 1 Linux | 1 Linux Kernel | 2025-10-01 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: mtd: spinand: winbond: Fix 512GW, 01GW, 01JW and 02JW ECC information These four chips: * W25N512GW * W25N01GW * W25N01JW * W25N02JW all require a single bit of ECC strength and thus feature an on-die Hamming-like ECC engine. There is no point in filling a ->get_status() callback for them because the main ECC status bytes are located in standard places, and retrieving the number of bitflips in case of corrected chunk is both useless and unsupported (if there are bitflips, then there is 1 at most, so no need to query the chip for that). Without this change, a kernel warning triggers every time a bit flips. | ||||
| CVE-2021-47496 | 1 Linux | 1 Linux Kernel | 2025-09-24 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: net/tls: Fix flipped sign in tls_err_abort() calls sk->sk_err appears to expect a positive value, a convention that ktls doesn't always follow and that leads to memory corruption in other code. For instance, [kworker] tls_encrypt_done(..., err=<negative error from crypto request>) tls_err_abort(.., err) sk->sk_err = err; [task] splice_from_pipe_feed ... tls_sw_do_sendpage if (sk->sk_err) { ret = -sk->sk_err; // ret is positive splice_from_pipe_feed (continued) ret = actor(...) // ret is still positive and interpreted as bytes // written, resulting in underflow of buf->len and // sd->len, leading to huge buf->offset and bogus // addresses computed in later calls to actor() Fix all tls_err_abort() callers to pass a negative error code consistently and centralize the error-prone sign flip there, throwing in a warning to catch future misuse and uninlining the function so it really does only warn once. | ||||
| CVE-2021-47555 | 1 Linux | 1 Linux Kernel | 2025-09-18 | 4.4 Medium |
| In the Linux kernel, the following vulnerability has been resolved: net: vlan: fix underflow for the real_dev refcnt Inject error before dev_hold(real_dev) in register_vlan_dev(), and execute the following testcase: ip link add dev dummy1 type dummy ip link add name dummy1.100 link dummy1 type vlan id 100 ip link del dev dummy1 When the dummy netdevice is removed, we will get a WARNING as following: ======================================================================= refcount_t: decrement hit 0; leaking memory. WARNING: CPU: 2 PID: 0 at lib/refcount.c:31 refcount_warn_saturate+0xbf/0x1e0 and an endless loop of: ======================================================================= unregister_netdevice: waiting for dummy1 to become free. Usage count = -1073741824 That is because dev_put(real_dev) in vlan_dev_free() be called without dev_hold(real_dev) in register_vlan_dev(). It makes the refcnt of real_dev underflow. Move the dev_hold(real_dev) to vlan_dev_init() which is the call-back of ndo_init(). That makes dev_hold() and dev_put() for vlan's real_dev symmetrical. | ||||
| CVE-2024-26921 | 2 Linux, Redhat | 3 Linux Kernel, Enterprise Linux, Rhel Eus | 2025-09-16 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: inet: inet_defrag: prevent sk release while still in use ip_local_out() and other functions can pass skb->sk as function argument. If the skb is a fragment and reassembly happens before such function call returns, the sk must not be released. This affects skb fragments reassembled via netfilter or similar modules, e.g. openvswitch or ct_act.c, when run as part of tx pipeline. Eric Dumazet made an initial analysis of this bug. Quoting Eric: Calling ip_defrag() in output path is also implying skb_orphan(), which is buggy because output path relies on sk not disappearing. A relevant old patch about the issue was : 8282f27449bf ("inet: frag: Always orphan skbs inside ip_defrag()") [..] net/ipv4/ip_output.c depends on skb->sk being set, and probably to an inet socket, not an arbitrary one. If we orphan the packet in ipvlan, then downstream things like FQ packet scheduler will not work properly. We need to change ip_defrag() to only use skb_orphan() when really needed, ie whenever frag_list is going to be used. Eric suggested to stash sk in fragment queue and made an initial patch. However there is a problem with this: If skb is refragmented again right after, ip_do_fragment() will copy head->sk to the new fragments, and sets up destructor to sock_wfree. IOW, we have no choice but to fix up sk_wmem accouting to reflect the fully reassembled skb, else wmem will underflow. This change moves the orphan down into the core, to last possible moment. As ip_defrag_offset is aliased with sk_buff->sk member, we must move the offset into the FRAG_CB, else skb->sk gets clobbered. This allows to delay the orphaning long enough to learn if the skb has to be queued or if the skb is completing the reasm queue. In the former case, things work as before, skb is orphaned. This is safe because skb gets queued/stolen and won't continue past reasm engine. In the latter case, we will steal the skb->sk reference, reattach it to the head skb, and fix up wmem accouting when inet_frag inflates truesize. | ||||
| CVE-2023-25610 | 1 Fortinet | 8 Fortianalyzer, Fortimanager, Fortios and 5 more | 2025-07-24 | 9.3 Critical |
| A buffer underwrite ('buffer underflow') vulnerability in the administrative interface of Fortinet FortiOS version 7.2.0 through 7.2.3, version 7.0.0 through 7.0.6, version 6.4.0 through 6.4.11 and version 6.2.12 and below, FortiProxy version 7.2.0 through 7.2.2, version 7.0.0 through 7.0.8, version 2.0.12 and below and FortiOS-6K7K version 7.0.5, version 6.4.0 through 6.4.10 and version 6.2.0 through 6.2.10 and below allows a remote unauthenticated attacker to execute arbitrary code or commands via specifically crafted requests. | ||||
| CVE-2025-20695 | 3 Google, Mediatek, Openwrt | 14 Android, Mt6639, Mt6653 and 11 more | 2025-07-14 | 6.5 Medium |
| In Bluetooth FW, there is a possible system crash due to an uncaught exception. This could lead to remote denial of service with no additional execution privileges needed. User interaction is not needed for exploitation. Patch ID: ALPS09741871; Issue ID: MSV-3317. | ||||
| CVE-2025-20694 | 3 Google, Mediatek, Openwrt | 40 Android, Mt2718, Mt6639 and 37 more | 2025-07-14 | 6.5 Medium |
| In Bluetooth FW, there is a possible system crash due to an uncaught exception. This could lead to remote denial of service with no additional execution privileges needed. User interaction is not needed for exploitation. Patch ID: ALPS09752821; Issue ID: MSV-3342. | ||||