Total
850 CVE
CVE | Vendors | Products | Updated | CVSS v3.1 |
---|---|---|---|---|
CVE-2023-25824 | 1 Mod Gnutls Project | 1 Mod Gnutls | 2025-03-10 | 7.5 High |
Mod_gnutls is a TLS module for Apache HTTPD based on GnuTLS. Versions from 0.9.0 to 0.12.0 (including) did not properly fail blocking read operations on TLS connections when the transport hit timeouts. Instead it entered an endless loop retrying the read operation, consuming CPU resources. This could be exploited for denial of service attacks. If trace level logging was enabled, it would also produce an excessive amount of log output during the loop, consuming disk space. The problem has been fixed in commit d7eec4e598158ab6a98bf505354e84352f9715ec, please update to version 0.12.1. There are no workarounds, users who cannot update should apply the errno fix detailed in the security advisory. | ||||
CVE-2024-26767 | 2 Linux, Redhat | 2 Linux Kernel, Enterprise Linux | 2025-03-07 | 5.5 Medium |
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: fixed integer types and null check locations [why]: issues fixed: - comparison with wider integer type in loop condition which can cause infinite loops - pointer dereference before null check | ||||
CVE-2023-27560 | 1 Phpseclib | 1 Phpseclib | 2025-03-06 | 7.5 High |
Math/PrimeField.php in phpseclib 3.x before 3.0.19 has an infinite loop with composite primefields. | ||||
CVE-2023-4010 | 2 Linux, Redhat | 2 Linux Kernel, Enterprise Linux | 2025-03-05 | 4.6 Medium |
A flaw was found in the USB Host Controller Driver framework in the Linux kernel. The usb_giveback_urb function has a logic loophole in its implementation. Due to the inappropriate judgment condition of the goto statement, the function cannot return under the input of a specific malformed descriptor file, so it falls into an endless loop, resulting in a denial of service. | ||||
CVE-2025-27497 | 2025-03-05 | N/A | ||
OpenDJ is an LDAPv3 compliant directory service. OpenDJ prior to 4.9.3 contains a denial-of-service (DoS) vulnerability that causes the server to become unresponsive to all LDAP requests without crashing or restarting. This issue occurs when an alias loop exists in the LDAP database. If an ldapsearch request is executed with alias dereferencing set to "always" on this alias entry, the server stops responding to all future requests. Fortunately, the server can be restarted without data corruption. This vulnerability is fixed in 4.9.3. | ||||
CVE-2025-1695 | 1 F5 | 1 Nginx | 2025-03-05 | 5.3 Medium |
In NGINX Unit before version 1.34.2 with the Java Language Module in use, undisclosed requests can lead to an infinite loop and cause an increase in CPU resource utilization. This vulnerability allows a remote attacker to cause a degradation that can lead to a limited denial-of-service (DoS). There is no control plane exposure; this is a data plane issue only. Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated. | ||||
CVE-2024-36990 | 1 Splunk | 2 Splunk, Splunk Cloud Platform | 2025-02-28 | 6.5 Medium |
In Splunk Enterprise versions below 9.2.2, 9.1.5, and 9.0.10 and Splunk Cloud Platform versions below 9.2.2403.100, an authenticated, low-privileged user that does not hold the admin or power Splunk roles could send a specially crafted HTTP POST request to the datamodel/web REST endpoint in Splunk Enterprise, potentially causing a denial of service. | ||||
CVE-2023-20999 | 1 Google | 1 Android | 2025-02-25 | 5.5 Medium |
In multiple locations, there is a possible way to trigger a persistent reboot loop due to improper input validation. This could lead to local denial of service with User execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-13Android ID: A-246750467 | ||||
CVE-2023-20998 | 1 Google | 1 Android | 2025-02-25 | 5.5 Medium |
In multiple locations, there is a possible way to trigger a persistent reboot loop due to improper input validation. This could lead to local denial of service with User execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-13Android ID: A-246749936 | ||||
CVE-2023-20997 | 1 Google | 1 Android | 2025-02-25 | 5.5 Medium |
In multiple locations, there is a possible way to trigger a persistent reboot loop due to improper input validation. This could lead to local denial of service with User execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-13Android ID: A-246749702 | ||||
CVE-2023-20996 | 1 Google | 1 Android | 2025-02-25 | 5.5 Medium |
In multiple locations, there is a possible way to trigger a persistent reboot loop due to improper input validation. This could lead to local denial of service with User execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-13Android ID: A-246749764 | ||||
CVE-2025-21667 | 1 Linux | 1 Linux Kernel | 2025-02-25 | 5.5 Medium |
In the Linux kernel, the following vulnerability has been resolved: iomap: avoid avoid truncating 64-bit offset to 32 bits on 32-bit kernels, iomap_write_delalloc_scan() was inadvertently using a 32-bit position due to folio_next_index() returning an unsigned long. This could lead to an infinite loop when writing to an xfs filesystem. | ||||
CVE-2025-21681 | 1 Linux | 1 Linux Kernel | 2025-02-21 | 5.5 Medium |
In the Linux kernel, the following vulnerability has been resolved: openvswitch: fix lockup on tx to unregistering netdev with carrier Commit in a fixes tag attempted to fix the issue in the following sequence of calls: do_output -> ovs_vport_send -> dev_queue_xmit -> __dev_queue_xmit -> netdev_core_pick_tx -> skb_tx_hash When device is unregistering, the 'dev->real_num_tx_queues' goes to zero and the 'while (unlikely(hash >= qcount))' loop inside the 'skb_tx_hash' becomes infinite, locking up the core forever. But unfortunately, checking just the carrier status is not enough to fix the issue, because some devices may still be in unregistering state while reporting carrier status OK. One example of such device is a net/dummy. It sets carrier ON on start, but it doesn't implement .ndo_stop to set the carrier off. And it makes sense, because dummy doesn't really have a carrier. Therefore, while this device is unregistering, it's still easy to hit the infinite loop in the skb_tx_hash() from the OVS datapath. There might be other drivers that do the same, but dummy by itself is important for the OVS ecosystem, because it is frequently used as a packet sink for tcpdump while debugging OVS deployments. And when the issue is hit, the only way to recover is to reboot. Fix that by also checking if the device is running. The running state is handled by the net core during unregistering, so it covers unregistering case better, and we don't really need to send packets to devices that are not running anyway. While only checking the running state might be enough, the carrier check is preserved. The running and the carrier states seem disjoined throughout the code and different drivers. And other core functions like __dev_direct_xmit() check both before attempting to transmit a packet. So, it seems safer to check both flags in OVS as well. | ||||
CVE-2022-37013 | 1 Unified-automation | 1 Opc Ua C\+\+ Demo Server | 2025-02-18 | 7.5 High |
This vulnerability allows remote attackers to create a denial-of-service condition on affected installations of Unified Automation OPC UA C++ Demo Server 1.7.6-537 [with vendor rollup]. Authentication is not required to exploit this vulnerability. The specific flaw exists within the handling of certificates. A crafted certificate can force the server into an infinite loop. An attacker can leverage this vulnerability to create a denial-of-service condition on the system. Was ZDI-CAN-17203. | ||||
CVE-2024-2757 | 2025-02-13 | 7.5 High | ||
In PHP 8.3.* before 8.3.5, function mb_encode_mimeheader() runs endlessly for some inputs that contain long strings of non-space characters followed by a space. This could lead to a potential DoS attack if a hostile user sends data to an application that uses this function. | ||||
CVE-2024-25710 | 2 Apache, Redhat | 9 Commons Compress, Amq Streams, Camel Quarkus and 6 more | 2025-02-13 | 8.1 High |
Loop with Unreachable Exit Condition ('Infinite Loop') vulnerability in Apache Commons Compress.This issue affects Apache Commons Compress: from 1.3 through 1.25.0. Users are recommended to upgrade to version 1.26.0 which fixes the issue. | ||||
CVE-2023-45233 | 2 Redhat, Tianocore | 3 Enterprise Linux, Rhel Eus, Edk2 | 2025-02-13 | 7.5 High |
EDK2's Network Package is susceptible to an infinite lop vulnerability when parsing a PadN option in the Destination Options header of IPv6. This vulnerability can be exploited by an attacker to gain unauthorized access and potentially lead to a loss of Availability. | ||||
CVE-2023-45232 | 2 Redhat, Tianocore | 3 Enterprise Linux, Rhel Eus, Edk2 | 2025-02-13 | 7.5 High |
EDK2's Network Package is susceptible to an infinite loop vulnerability when parsing unknown options in the Destination Options header of IPv6. This vulnerability can be exploited by an attacker to gain unauthorized access and potentially lead to a loss of Availability. | ||||
CVE-2024-30251 | 2 Aio-libs Project, Redhat | 3 Aiohttp, Ansible Automation Platform, Rhui | 2025-02-13 | 7.5 High |
aiohttp is an asynchronous HTTP client/server framework for asyncio and Python. In affected versions an attacker can send a specially crafted POST (multipart/form-data) request. When the aiohttp server processes it, the server will enter an infinite loop and be unable to process any further requests. An attacker can stop the application from serving requests after sending a single request. This issue has been addressed in version 3.9.4. Users are advised to upgrade. Users unable to upgrade may manually apply a patch to their systems. Please see the linked GHSA for instructions. | ||||
CVE-2024-24788 | 1 Redhat | 14 Ansible Automation Platform, Cost Management, Cryostat and 11 more | 2025-02-13 | 5.9 Medium |
A malformed DNS message in response to a query can cause the Lookup functions to get stuck in an infinite loop. |