Total
937 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2021-4185 | 4 Debian, Fedoraproject, Oracle and 1 more | 5 Debian Linux, Fedora, Http Server and 2 more | 2026-06-17 | 5.0 MEDIUM | 7.5 HIGH |
| Infinite loop in the RTMPT dissector in Wireshark 3.6.0 and 3.4.0 to 3.4.10 allows denial of service via packet injection or crafted capture file | |||||
| CVE-2021-4184 | 4 Debian, Fedoraproject, Oracle and 1 more | 5 Debian Linux, Fedora, Http Server and 2 more | 2026-06-17 | 5.0 MEDIUM | 7.5 HIGH |
| Infinite loop in the BitTorrent DHT dissector in Wireshark 3.6.0 and 3.4.0 to 3.4.10 allows denial of service via packet injection or crafted capture file | |||||
| CVE-2021-4182 | 3 Fedoraproject, Oracle, Wireshark | 4 Fedora, Http Server, Zfs Storage Appliance Kit and 1 more | 2026-06-17 | 5.0 MEDIUM | 7.5 HIGH |
| Crash in the RFC 7468 dissector in Wireshark 3.6.0 and 3.4.0 to 3.4.10 allows denial of service via packet injection or crafted capture file | |||||
| CVE-2021-4044 | 3 Netapp, Nodejs, Openssl | 26 500f, 500f Firmware, A250 and 23 more | 2026-06-17 | 5.0 MEDIUM | 7.5 HIGH |
| Internally libssl in OpenSSL calls X509_verify_cert() on the client side to verify a certificate supplied by a server. That function may return a negative return value to indicate an internal error (for example out of memory). Such a negative return value is mishandled by OpenSSL and will cause an IO function (such as SSL_connect() or SSL_do_handshake()) to not indicate success and a subsequent call to SSL_get_error() to return the value SSL_ERROR_WANT_RETRY_VERIFY. This return value is only supposed to be returned by OpenSSL if the application has previously called SSL_CTX_set_cert_verify_callback(). Since most applications do not do this the SSL_ERROR_WANT_RETRY_VERIFY return value from SSL_get_error() will be totally unexpected and applications may not behave correctly as a result. The exact behaviour will depend on the application but it could result in crashes, infinite loops or other similar incorrect responses. This issue is made more serious in combination with a separate bug in OpenSSL 3.0 that will cause X509_verify_cert() to indicate an internal error when processing a certificate chain. This will occur where a certificate does not include the Subject Alternative Name extension but where a Certificate Authority has enforced name constraints. This issue can occur even with valid chains. By combining the two issues an attacker could induce incorrect, application dependent behaviour. Fixed in OpenSSL 3.0.1 (Affected 3.0.0). | |||||
| CVE-2021-47617 | 1 Linux | 1 Linux Kernel | 2026-06-17 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: PCI: pciehp: Fix infinite loop in IRQ handler upon power fault The Power Fault Detected bit in the Slot Status register differs from all other hotplug events in that it is sticky: It can only be cleared after turning off slot power. Per PCIe r5.0, sec. 6.7.1.8: If a power controller detects a main power fault on the hot-plug slot, it must automatically set its internal main power fault latch [...]. The main power fault latch is cleared when software turns off power to the hot-plug slot. The stickiness used to cause interrupt storms and infinite loops which were fixed in 2009 by commits 5651c48cfafe ("PCI pciehp: fix power fault interrupt storm problem") and 99f0169c17f3 ("PCI: pciehp: enable software notification on empty slots"). Unfortunately in 2020 the infinite loop issue was inadvertently reintroduced by commit 8edf5332c393 ("PCI: pciehp: Fix MSI interrupt race"): The hardirq handler pciehp_isr() clears the PFD bit until pciehp's power_fault_detected flag is set. That happens in the IRQ thread pciehp_ist(), which never learns of the event because the hardirq handler is stuck in an infinite loop. Fix by setting the power_fault_detected flag already in the hardirq handler. | |||||
| CVE-2021-47406 | 1 Linux | 1 Linux Kernel | 2026-06-17 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: ext4: add error checking to ext4_ext_replay_set_iblocks() If the call to ext4_map_blocks() fails due to an corrupted file system, ext4_ext_replay_set_iblocks() can get stuck in an infinite loop. This could be reproduced by running generic/526 with a file system that has inline_data and fast_commit enabled. The system will repeatedly log to the console: EXT4-fs warning (device dm-3): ext4_block_to_path:105: block 1074800922 > max in inode 131076 and the stack that it gets stuck in is: ext4_block_to_path+0xe3/0x130 ext4_ind_map_blocks+0x93/0x690 ext4_map_blocks+0x100/0x660 skip_hole+0x47/0x70 ext4_ext_replay_set_iblocks+0x223/0x440 ext4_fc_replay_inode+0x29e/0x3b0 ext4_fc_replay+0x278/0x550 do_one_pass+0x646/0xc10 jbd2_journal_recover+0x14a/0x270 jbd2_journal_load+0xc4/0x150 ext4_load_journal+0x1f3/0x490 ext4_fill_super+0x22d4/0x2c00 With this patch, generic/526 still fails, but system is no longer locking up in a tight loop. It's likely the root casue is that fast_commit replay is corrupting file systems with inline_data, and we probably need to add better error handling in the fast commit replay code path beyond what is done here, which essentially just breaks the infinite loop without reporting the to the higher levels of the code. | |||||
| CVE-2021-46828 | 2 Debian, Libtirpc Project | 2 Debian Linux, Libtirpc | 2026-06-17 | N/A | 7.5 HIGH |
| In libtirpc before 1.3.3rc1, remote attackers could exhaust the file descriptors of a process that uses libtirpc because idle TCP connections are mishandled. This can, in turn, lead to an svc_run infinite loop without accepting new connections. | |||||
| CVE-2021-45445 | 1 Unisys | 1 Clearpath Mcp Tcp\/ip Networking Services | 2026-06-17 | 5.0 MEDIUM | 7.5 HIGH |
| Unisys ClearPath MCP TCP/IP Networking Services 59.1, 60.0, and 62.0 has an Infinite Loop. | |||||
| CVE-2021-45297 | 1 Gpac | 1 Gpac | 2026-06-17 | 4.3 MEDIUM | 5.5 MEDIUM |
| An infinite loop vulnerability exists in Gpac 1.0.1 in gf_get_bit_size. | |||||
| CVE-2021-45257 | 1 Nasm | 1 Netwide Assembler | 2026-06-17 | 4.3 MEDIUM | 5.5 MEDIUM |
| An infinite loop vulnerability exists in nasm 2.16rc0 via the gpaste_tokens function. | |||||
| CVE-2021-44924 | 1 Gpac | 1 Gpac | 2026-06-17 | 4.3 MEDIUM | 5.5 MEDIUM |
| An infinite loop vulnerability exists in gpac 1.1.0 in the gf_log function, which causes a Denial of Service. | |||||
| CVE-2021-44718 | 1 Wolfssl | 1 Wolfssl | 2026-06-17 | N/A | 5.9 MEDIUM |
| wolfSSL through 5.0.0 allows an attacker to cause a denial of service and infinite loop in the client component by sending crafted traffic from a Machine-in-the-Middle (MITM) position. The root cause is that the client module accepts TLS messages that normally are only sent to TLS servers. | |||||
| CVE-2021-43172 | 1 Nlnetlabs | 1 Routinator | 2026-06-17 | 5.0 MEDIUM | 7.5 HIGH |
| NLnet Labs Routinator prior to 0.10.2 happily processes a chain of RRDP repositories of infinite length causing it to never finish a validation run. In RPKI, a CA can choose the RRDP repository it wishes to publish its data in. By continuously generating a new child CA that only consists of another CA using a different RRDP repository, a malicious CA can create a chain of CAs of de-facto infinite length. Routinator prior to version 0.10.2 did not contain a limit on the length of such a chain and will therefore continue to process this chain forever. As a result, the validation run will never finish, leading to Routinator continuing to serve the old data set or, if in the initial validation run directly after starting, never serve any data at all. | |||||
| CVE-2021-42715 | 3 Debian, Fedoraproject, Nothings | 3 Debian Linux, Fedora, Stb Image.h | 2026-06-17 | 4.3 MEDIUM | 5.5 MEDIUM |
| An issue was discovered in stb stb_image.h 1.33 through 2.27. The HDR loader parsed truncated end-of-file RLE scanlines as an infinite sequence of zero-length runs. An attacker could potentially have caused denial of service in applications using stb_image by submitting crafted HDR files. | |||||
| CVE-2021-42260 | 2 Debian, Tinyxml Project | 2 Debian Linux, Tinyxml | 2026-06-17 | 5.0 MEDIUM | 7.5 HIGH |
| TinyXML through 2.6.2 has an infinite loop in TiXmlParsingData::Stamp in tinyxmlparser.cpp via the TIXML_UTF_LEAD_0 case. It can be triggered by a crafted XML message and leads to a denial of service. | |||||
| CVE-2021-42143 | 1 Contiki-ng | 1 Tinydtls | 2026-06-17 | N/A | 9.1 CRITICAL |
| An issue was discovered in Contiki-NG tinyDTLS through master branch 53a0d97. An infinite loop bug exists during the handling of a ClientHello handshake message. This bug allows remote attackers to cause a denial of service by sending a malformed ClientHello handshake message with an odd length of cipher suites, which triggers an infinite loop (consuming all resources) and a buffer over-read that can disclose sensitive information. | |||||
| CVE-2021-42084 | 1 Zammad | 1 Zammad | 2026-06-17 | 4.0 MEDIUM | 6.5 MEDIUM |
| An issue was discovered in Zammad before 4.1.1. An attacker with valid agent credentials may send a series of crafted requests that cause an endless loop and thus cause denial of service. | |||||
| CVE-2021-42040 | 1 Mediawiki | 1 Mediawiki | 2026-06-17 | 5.0 MEDIUM | 7.5 HIGH |
| An issue was discovered in MediaWiki through 1.36.2. A parser function related to loop control allowed for an infinite loop (and php-fpm hang) within the Loops extension because egLoopsCountLimit is mishandled. This could lead to memory exhaustion. | |||||
| CVE-2021-41973 | 2 Apache, Oracle | 9 Mina, Banking Payments, Banking Trade Finance Process Management and 6 more | 2026-06-17 | 4.3 MEDIUM | 6.5 MEDIUM |
| In Apache MINA, a specifically crafted, malformed HTTP request may cause the HTTP Header decoder to loop indefinitely. The decoder assumed that the HTTP Header begins at the beginning of the buffer and loops if there is more data than expected. Please update MINA to 2.1.5 or greater. | |||||
| CVE-2021-41079 | 3 Apache, Debian, Netapp | 3 Tomcat, Debian Linux, Management Services For Element Software And Netapp Hci | 2026-06-17 | 4.3 MEDIUM | 7.5 HIGH |
| Apache Tomcat 8.5.0 to 8.5.63, 9.0.0-M1 to 9.0.43 and 10.0.0-M1 to 10.0.2 did not properly validate incoming TLS packets. When Tomcat was configured to use NIO+OpenSSL or NIO2+OpenSSL for TLS, a specially crafted packet could be used to trigger an infinite loop resulting in a denial of service. | |||||