Vulnerabilities (CVE)

Filtered by CWE-835
Total 700 CVE
CVE Vendors Products Updated CVSS v2 CVSS v3
CVE-2023-0437 1 Mongodb 1 C Driver 2025-02-13 N/A 5.3 MEDIUM
When calling bson_utf8_validate on some inputs a loop with an exit condition that cannot be reached may occur, i.e. an infinite loop. This issue affects All MongoDB C Driver versions prior to versions 1.25.0.
CVE-2024-6790 2025-02-03 N/A 4.0 MEDIUM
Loop with Unreachable Exit Condition ('Infinite Loop') vulnerability in Arm Ltd Bifrost GPU Kernel Driver, Arm Ltd Valhall GPU Kernel Driver, Arm Ltd Arm 5th Gen GPU Architecture Kernel Driver allows a non-privileged user process to make valid GPU memory processing operations, including via WebGL or WebGPU, to cause the whole system to become unresponsive.This issue affects Bifrost GPU Kernel Driver: r44p1, from r46p0 through r49p0, from r50p0 through r51p0; Valhall GPU Kernel Driver: r44p1, from r46p0 through r49p0, from r50p0 through r51p0; Arm 5th Gen GPU Architecture Kernel Driver: r44p1, from r46p0 through r49p0, from r50p0 through r51p0.
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 5.4 MEDIUM
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 6.3 MEDIUM
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 5.3 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-55565 2024-12-12 N/A 4.3 MEDIUM
nanoid (aka Nano ID) before 5.0.9 mishandles non-integer values. 3.3.8 is also a fixed version.
CVE-2024-23352 1 Qualcomm 210 315 5g Iot Modem, 315 5g Iot Modem Firmware, Ar8035 and 207 more 2024-11-26 N/A 7.5 HIGH
Transient DOS when NAS receives ODAC criteria of length 1 and type 1 in registration accept OTA.
CVE-2024-24788 2024-11-21 N/A 5.9 MEDIUM
A malformed DNS message in response to a query can cause the Lookup functions to get stuck in an infinite loop.
CVE-2024-6227 1 Aimstack 1 Aim 2024-11-21 N/A 7.5 HIGH
A vulnerability in aimhubio/aim version 3.19.3 allows an attacker to cause an infinite loop by configuring the remote tracking server to point at itself. This results in the server endlessly connecting to itself, rendering it unable to respond to other connections.
CVE-2024-6061 1 Gpac 1 Gpac 2024-11-21 1.7 LOW 3.3 LOW
A vulnerability has been found in GPAC 2.5-DEV-rev228-g11067ea92-master and classified as problematic. Affected by this vulnerability is the function isoffin_process of the file src/filters/isoffin_read.c of the component MP4Box. The manipulation leads to infinite loop. It is possible to launch the attack on the local host. The exploit has been disclosed to the public and may be used. The identifier of the patch is 20c0f29139a82779b86453ce7f68d0681ec7624c. It is recommended to apply a patch to fix this issue. The identifier VDB-268789 was assigned to this vulnerability.
CVE-2024-5949 1 Deepseaelectronics 2 Dse855, Dse855 Firmware 2024-11-21 N/A 6.5 MEDIUM
Deep Sea Electronics DSE855 Multipart Boundary Infinite Loop Denial-of-Service Vulnerability. This vulnerability allows network-adjacent attackers to create a denial-of-service condition on affected installations of Deep Sea Electronics DSE855 devices. Authentication is not required to exploit this vulnerability. The specific flaw exists within the handling of multipart boundaries. The issue results from a logic error that can lead to an infinite loop. An attacker can leverage this vulnerability to create a denial-of-service condition on the system. Was ZDI-CAN-23171.
CVE-2024-41088 1 Linux 1 Linux Kernel 2024-11-21 N/A 5.5 MEDIUM
In the Linux kernel, the following vulnerability has been resolved: can: mcp251xfd: fix infinite loop when xmit fails When the mcp251xfd_start_xmit() function fails, the driver stops processing messages, and the interrupt routine does not return, running indefinitely even after killing the running application. Error messages: [ 441.298819] mcp251xfd spi2.0 can0: ERROR in mcp251xfd_start_xmit: -16 [ 441.306498] mcp251xfd spi2.0 can0: Transmit Event FIFO buffer not empty. (seq=0x000017c7, tef_tail=0x000017cf, tef_head=0x000017d0, tx_head=0x000017d3). ... and repeat forever. The issue can be triggered when multiple devices share the same SPI interface. And there is concurrent access to the bus. The problem occurs because tx_ring->head increments even if mcp251xfd_start_xmit() fails. Consequently, the driver skips one TX package while still expecting a response in mcp251xfd_handle_tefif_one(). Resolve the issue by starting a workqueue to write the tx obj synchronously if err = -EBUSY. In case of another error, decrement tx_ring->head, remove skb from the echo stack, and drop the message. [mkl: use more imperative wording in patch description]
CVE-2024-40995 1 Linux 1 Linux Kernel 2024-11-21 N/A 5.5 MEDIUM
In the Linux kernel, the following vulnerability has been resolved: net/sched: act_api: fix possible infinite loop in tcf_idr_check_alloc() syzbot found hanging tasks waiting on rtnl_lock [1] A reproducer is available in the syzbot bug. When a request to add multiple actions with the same index is sent, the second request will block forever on the first request. This holds rtnl_lock, and causes tasks to hang. Return -EAGAIN to prevent infinite looping, while keeping documented behavior. [1] INFO: task kworker/1:0:5088 blocked for more than 143 seconds. Not tainted 6.9.0-rc4-syzkaller-00173-g3cdb45594619 #0 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/1:0 state:D stack:23744 pid:5088 tgid:5088 ppid:2 flags:0x00004000 Workqueue: events_power_efficient reg_check_chans_work Call Trace: <TASK> context_switch kernel/sched/core.c:5409 [inline] __schedule+0xf15/0x5d00 kernel/sched/core.c:6746 __schedule_loop kernel/sched/core.c:6823 [inline] schedule+0xe7/0x350 kernel/sched/core.c:6838 schedule_preempt_disabled+0x13/0x30 kernel/sched/core.c:6895 __mutex_lock_common kernel/locking/mutex.c:684 [inline] __mutex_lock+0x5b8/0x9c0 kernel/locking/mutex.c:752 wiphy_lock include/net/cfg80211.h:5953 [inline] reg_leave_invalid_chans net/wireless/reg.c:2466 [inline] reg_check_chans_work+0x10a/0x10e0 net/wireless/reg.c:2481
CVE-2024-40060 1 Wcharczuk 1 Go-chart 2024-11-21 N/A 7.5 HIGH
go-chart v2.1.1 was discovered to contain an infinite loop via the drawCanvas() function.