Total
628 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2025-21667 | 1 Linux | 1 Linux Kernel | 2025-02-03 | N/A | 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-21665 | 1 Linux | 1 Linux Kernel | 2025-02-03 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: filemap: avoid truncating 64-bit offset to 32 bits On 32-bit kernels, folio_seek_hole_data() was inadvertently truncating a 64-bit value to 32 bits, leading to a possible infinite loop when writing to an xfs filesystem. | |||||
| CVE-2022-48630 | 1 Linux | 1 Linux Kernel | 2025-02-03 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: crypto: qcom-rng - fix infinite loop on requests not multiple of WORD_SZ The commit referenced in the Fixes tag removed the 'break' from the else branch in qcom_rng_read(), causing an infinite loop whenever 'max' is not a multiple of WORD_SZ. This can be reproduced e.g. by running: kcapi-rng -b 67 >/dev/null There are many ways to fix this without adding back the 'break', but they all seem more awkward than simply adding it back, so do just that. Tested on a machine with Qualcomm Amberwing processor. | |||||
| CVE-2024-57940 | 1 Linux | 1 Linux Kernel | 2025-02-02 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: exfat: fix the infinite loop in exfat_readdir() If the file system is corrupted so that a cluster is linked to itself in the cluster chain, and there is an unused directory entry in the cluster, 'dentry' will not be incremented, causing condition 'dentry < max_dentries' unable to prevent an infinite loop. This infinite loop causes s_lock not to be released, and other tasks will hang, such as exfat_sync_fs(). This commit stops traversing the cluster chain when there is unused directory entry in the cluster to avoid this infinite loop. | |||||
| CVE-2023-30300 | 1 W3 | 1 Webassembly | 2025-01-30 | N/A | 5.5 MEDIUM |
| An issue in the component hang.wasm of WebAssembly 1.0 causes an infinite loop. | |||||
| CVE-2025-23221 | 2025-01-20 | N/A | N/A | ||
| Fedify is a TypeScript library for building federated server apps powered by ActivityPub and other standards. This vulnerability allows a user to maneuver the Webfinger mechanism to perform a GET request to any internal resource on any Host, Port, URL combination regardless of present security mechanisms, and forcing the victim’s server into an infinite loop causing Denial of Service. Moreover, this issue can also be maneuvered into performing a Blind SSRF attack. This vulnerability is fixed in 1.0.14, 1.1.11, 1.2.11, and 1.3.4. | |||||
| CVE-2024-35981 | 1 Linux | 1 Linux Kernel | 2025-01-16 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: virtio_net: Do not send RSS key if it is not supported There is a bug when setting the RSS options in virtio_net that can break the whole machine, getting the kernel into an infinite loop. Running the following command in any QEMU virtual machine with virtionet will reproduce this problem: # ethtool -X eth0 hfunc toeplitz This is how the problem happens: 1) ethtool_set_rxfh() calls virtnet_set_rxfh() 2) virtnet_set_rxfh() calls virtnet_commit_rss_command() 3) virtnet_commit_rss_command() populates 4 entries for the rss scatter-gather 4) Since the command above does not have a key, then the last scatter-gatter entry will be zeroed, since rss_key_size == 0. sg_buf_size = vi->rss_key_size; 5) This buffer is passed to qemu, but qemu is not happy with a buffer with zero length, and do the following in virtqueue_map_desc() (QEMU function): if (!sz) { virtio_error(vdev, "virtio: zero sized buffers are not allowed"); 6) virtio_error() (also QEMU function) set the device as broken vdev->broken = true; 7) Qemu bails out, and do not repond this crazy kernel. 8) The kernel is waiting for the response to come back (function virtnet_send_command()) 9) The kernel is waiting doing the following : while (!virtqueue_get_buf(vi->cvq, &tmp) && !virtqueue_is_broken(vi->cvq)) cpu_relax(); 10) None of the following functions above is true, thus, the kernel loops here forever. Keeping in mind that virtqueue_is_broken() does not look at the qemu `vdev->broken`, so, it never realizes that the vitio is broken at QEMU side. Fix it by not sending RSS commands if the feature is not available in the device. | |||||
| CVE-2023-2879 | 2 Debian, Wireshark | 2 Debian Linux, Wireshark | 2025-01-15 | N/A | 7.5 HIGH |
| GDSDB infinite loop in Wireshark 4.0.0 to 4.0.5 and 3.6.0 to 3.6.13 allows denial of service via packet injection or crafted capture file | |||||
| CVE-2023-2952 | 2 Debian, Wireshark | 2 Debian Linux, Wireshark | 2025-01-13 | N/A | 6.5 MEDIUM |
| XRA dissector infinite loop in Wireshark 4.0.0 to 4.0.5 and 3.6.0 to 3.6.13 allows denial of service via packet injection or crafted capture file | |||||
| CVE-2017-13313 | 1 Google | 1 Android | 2024-12-18 | N/A | 6.5 MEDIUM |
| In ElementaryStreamQueue::dequeueAccessUnitMPEG4Video of ESQueue.cpp, there is a possible infinite loop leading to resource exhaustion due to an incorrect bounds check. This could lead to remote denial of service with no additional execution privileges needed. User interaction is needed for exploitation. | |||||
| CVE-2024-1931 | 2 Fedoraproject, Nlnetlabs | 2 Fedora, Unbound | 2024-12-17 | N/A | 7.5 HIGH |
| NLnet Labs Unbound version 1.18.0 up to and including version 1.19.1 contain a vulnerability that can cause denial of service by a certain code path that can lead to an infinite loop. Unbound 1.18.0 introduced a feature that removes EDE records from responses with size higher than the client's advertised buffer size. Before removing all the EDE records however, it would try to see if trimming the extra text fields on those records would result in an acceptable size while still retaining the EDE codes. Due to an unchecked condition, the code that trims the text of the EDE records could loop indefinitely. This happens when Unbound would reply with attached EDE information on a positive reply and the client's buffer size is smaller than the needed space to include EDE records. The vulnerability can only be triggered when the 'ede: yes' option is used; non default configuration. From version 1.19.2 on, the code is fixed to avoid looping indefinitely. | |||||
| CVE-2024-53980 | 2024-11-29 | N/A | N/A | ||
| RIOT is an open-source microcontroller operating system, designed to match the requirements of Internet of Things (IoT) devices and other embedded devices. A malicious actor can send a IEEE 802.15.4 packet with spoofed length byte and optionally spoofed FCS, which eventually results into an endless loop on a CC2538 as receiver. Before PR #20998, the receiver would check for the location of the CRC bit using the packet length byte by considering all 8 bits, instead of discarding bit 7, which is what the radio does. This then results into reading outside of the RX FIFO. Although it prints an error when attempting to read outside of the RX FIFO, it will continue doing this. This may lead to a discrepancy in the CRC check according to the firmware and the radio. If the CPU judges the CRC as correct and the radio is set to `AUTO_ACK`, when the packet requests and acknowledgment the CPU will go into the state `CC2538_STATE_TX_ACK`. However, if the radio judged the CRC as incorrect, it will not send an acknowledgment, and thus the `TXACKDONE` event will not fire. It will then never return to the state `CC2538_STATE_READY` since the baseband processing is still disabled. Then the CPU will be in an endless loop. Since setting to idle is not forced, it won't do it if the radio's state is not `CC2538_STATE_READY`. A fix has not yet been made. | |||||
| CVE-2024-23352 | 1 Qualcomm | 210 315 5g Iot Modem, 315 5g Iot Modem Firmware, Ar8035 and 207 more | 2024-11-26 | N/A | N/A |
| Transient DOS when NAS receives ODAC criteria of length 1 and type 1 in registration accept OTA. | |||||
| CVE-2024-50320 | 1 Ivanti | 1 Avalanche | 2024-11-18 | N/A | 7.5 HIGH |
| An infinite loop in Ivanti Avalanche before 6.4.6 allows a remote unauthenticated attacker to cause a denial of service. | |||||
| CVE-2024-50321 | 1 Ivanti | 1 Avalanche | 2024-11-18 | N/A | 7.5 HIGH |
| An infinite loop in Ivanti Avalanche before 6.4.6 allows a remote unauthenticated attacker to cause a denial of service. | |||||
| CVE-2024-50319 | 1 Ivanti | 1 Avalanche | 2024-11-18 | N/A | 7.5 HIGH |
| An infinite loop in Ivanti Avalanche before 6.4.6 allows a remote unauthenticated attacker to cause a denial of service. | |||||
| CVE-2024-11097 | 1 Razormist | 1 Student Record Management System | 2024-11-14 | N/A | 5.5 MEDIUM |
| A vulnerability has been found in SourceCodester Student Record Management System 1.0 and classified as problematic. This vulnerability affects unknown code of the component Main Menu. The manipulation leads to infinite loop. Attacking locally is a requirement. The exploit has been disclosed to the public and may be used. | |||||
| CVE-2024-33623 | 1 Level1 | 2 Wbr-6012, Wbr-6012 Firmware | 2024-11-13 | N/A | 7.5 HIGH |
| A denial of service vulnerability exists in the Web Application functionality of LevelOne WBR-6012 R0.40e6. A specially crafted HTTP request can lead to a reboot. An attacker can send an HTTP request to trigger this vulnerability. | |||||
| CVE-2024-35982 | 1 Linux | 1 Linux Kernel | 2024-11-05 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: batman-adv: Avoid infinite loop trying to resize local TT If the MTU of one of an attached interface becomes too small to transmit the local translation table then it must be resized to fit inside all fragments (when enabled) or a single packet. But if the MTU becomes too low to transmit even the header + the VLAN specific part then the resizing of the local TT will never succeed. This can for example happen when the usable space is 110 bytes and 11 VLANs are on top of batman-adv. In this case, at least 116 byte would be needed. There will just be an endless spam of batman_adv: batadv0: Forced to purge local tt entries to fit new maximum fragment MTU (110) in the log but the function will never finish. Problem here is that the timeout will be halved all the time and will then stagnate at 0 and therefore never be able to reduce the table even more. There are other scenarios possible with a similar result. The number of BATADV_TT_CLIENT_NOPURGE entries in the local TT can for example be too high to fit inside a packet. Such a scenario can therefore happen also with only a single VLAN + 7 non-purgable addresses - requiring at least 120 bytes. While this should be handled proactively when: * interface with too low MTU is added * VLAN is added * non-purgeable local mac is added * MTU of an attached interface is reduced * fragmentation setting gets disabled (which most likely requires dropping attached interfaces) not all of these scenarios can be prevented because batman-adv is only consuming events without the the possibility to prevent these actions (non-purgable MAC address added, MTU of an attached interface is reduced). It is therefore necessary to also make sure that the code is able to handle also the situations when there were already incompatible system configuration are present. | |||||
| CVE-2024-50011 | 1 Linux | 1 Linux Kernel | 2024-11-01 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: ASoC: Intel: soc-acpi-intel-rpl-match: add missing empty item There is no links_num in struct snd_soc_acpi_mach {}, and we test !link->num_adr as a condition to end the loop in hda_sdw_machine_select(). So an empty item in struct snd_soc_acpi_link_adr array is required. | |||||