Total
628 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2023-4511 | 1 Wireshark | 1 Wireshark | 2024-08-29 | N/A | 7.5 HIGH |
| BT SDP dissector infinite loop in Wireshark 4.0.0 to 4.0.7 and 3.6.0 to 3.6.15 allows denial of service via packet injection or crafted capture file | |||||
| CVE-2024-43828 | 1 Linux | 1 Linux Kernel | 2024-08-22 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: ext4: fix infinite loop when replaying fast_commit When doing fast_commit replay an infinite loop may occur due to an uninitialized extent_status struct. ext4_ext_determine_insert_hole() does not detect the replay and calls ext4_es_find_extent_range(), which will return immediately without initializing the 'es' variable. Because 'es' contains garbage, an integer overflow may happen causing an infinite loop in this function, easily reproducible using fstest generic/039. This commit fixes this issue by unconditionally initializing the structure in function ext4_es_find_extent_range(). Thanks to Zhang Yi, for figuring out the real problem! | |||||
| CVE-2024-41088 | 1 Linux | 1 Linux Kernel | 2024-08-22 | 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-08-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-36990 | 1 Splunk | 2 Splunk, Splunk Cloud Platform | 2024-08-21 | N/A | 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-2021-22197 | 1 Gitlab | 1 Gitlab | 2024-08-21 | 4.0 MEDIUM | 4.3 MEDIUM |
| An issue has been discovered in GitLab CE/EE affecting all versions starting from 10.6 where an infinite loop exist when an authenticated user with specific rights access a MR having source and target branch pointing to each other | |||||
| CVE-2018-12228 | 1 Sangoma | 1 Asterisk | 2024-08-15 | 6.8 MEDIUM | 6.5 MEDIUM |
| An issue was discovered in Asterisk Open Source 15.x before 15.4.1. When connected to Asterisk via TCP/TLS, if the client abruptly disconnects, or sends a specially crafted message, then Asterisk gets caught in an infinite loop while trying to read the data stream. This renders the system unusable. | |||||
| CVE-2017-9358 | 2 Asterisk, Sangoma | 2 Certified Asterisk, Asterisk | 2024-08-15 | 5.0 MEDIUM | 7.5 HIGH |
| A memory exhaustion vulnerability exists in Asterisk Open Source 13.x before 13.15.1 and 14.x before 14.4.1 and Certified Asterisk 13.13 before 13.13-cert4, which can be triggered by sending specially crafted SCCP packets causing an infinite loop and leading to memory exhaustion (by message logging in that loop). | |||||
| CVE-2024-42358 | 1 Msweet | 1 Pdfio | 2024-08-12 | N/A | 5.5 MEDIUM |
| PDFio is a simple C library for reading and writing PDF files. There is a denial of service (DOS) vulnerability in the TTF parser. Maliciously crafted TTF files can cause the program to utilize 100% of the Memory and enter an infinite loop. This can also lead to a heap-buffer-overflow vulnerability. An infinite loop occurs in the read_camp function by nGroups value. The ttf.h library is vulnerable. A value called nGroups is extracted from the file, and by changing that value, you can cause the program to utilize 100% of the Memory and enter an infinite loop. If the value of nGroups in the file is small, an infinite loop will not occur. This library, whether used as a standalone binary or as part of another application, is vulnerable to DOS attacks when parsing certain types of files. Automated systems, including web servers that use this code to convert PDF submissions into plaintext, can be DOSed if an attacker uploads a malicious TTF file. This issue has been addressed in release version 1.3.1. All users are advised to upgrade. There are no known workarounds for this vulnerability. | |||||
| CVE-2024-42240 | 1 Linux | 1 Linux Kernel | 2024-08-08 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: x86/bhi: Avoid warning in #DB handler due to BHI mitigation When BHI mitigation is enabled, if SYSENTER is invoked with the TF flag set then entry_SYSENTER_compat() uses CLEAR_BRANCH_HISTORY and calls the clear_bhb_loop() before the TF flag is cleared. This causes the #DB handler (exc_debug_kernel()) to issue a warning because single-step is used outside the entry_SYSENTER_compat() function. To address this issue, entry_SYSENTER_compat() should use CLEAR_BRANCH_HISTORY after making sure the TF flag is cleared. The problem can be reproduced with the following sequence: $ cat sysenter_step.c int main() { asm("pushf; pop %ax; bts $8,%ax; push %ax; popf; sysenter"); } $ gcc -o sysenter_step sysenter_step.c $ ./sysenter_step Segmentation fault (core dumped) The program is expected to crash, and the #DB handler will issue a warning. Kernel log: WARNING: CPU: 27 PID: 7000 at arch/x86/kernel/traps.c:1009 exc_debug_kernel+0xd2/0x160 ... RIP: 0010:exc_debug_kernel+0xd2/0x160 ... Call Trace: <#DB> ? show_regs+0x68/0x80 ? __warn+0x8c/0x140 ? exc_debug_kernel+0xd2/0x160 ? report_bug+0x175/0x1a0 ? handle_bug+0x44/0x90 ? exc_invalid_op+0x1c/0x70 ? asm_exc_invalid_op+0x1f/0x30 ? exc_debug_kernel+0xd2/0x160 exc_debug+0x43/0x50 asm_exc_debug+0x1e/0x40 RIP: 0010:clear_bhb_loop+0x0/0xb0 ... </#DB> <TASK> ? entry_SYSENTER_compat_after_hwframe+0x6e/0x8d </TASK> [ bp: Massage commit message. ] | |||||
| CVE-2024-5949 | 1 Deepseaelectronics | 2 Dse855, Dse855 Firmware | 2024-08-07 | 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-2017-15871 | 1 Serialize-to-js Project | 1 Serialize-to-js | 2024-08-05 | 5.0 MEDIUM | 7.5 HIGH |
| The deserialize function in serialize-to-js through 1.1.1 allows attackers to cause a denial of service via vectors involving an Immediately Invoked Function Expression "function()" substring, as demonstrated by a "function(){console.log(" call or a simple infinite loop. NOTE: the vendor agrees that denial of service can occur but notes that deserialize is explicitly listed as "harmful" within the README.md file | |||||
| CVE-2018-19826 | 1 Sass-lang | 1 Libsass | 2024-08-05 | 4.3 MEDIUM | 6.5 MEDIUM |
| In inspect.cpp in LibSass 3.5.5, a high memory footprint caused by an endless loop (containing a Sass::Inspect::operator()(Sass::String_Quoted*) stack frame) may cause a Denial of Service via crafted sass input files with stray '&' or '/' characters. NOTE: Upstream comments indicate this issue is closed as "won't fix" and "works as intended" by design | |||||
| CVE-2019-25040 | 2 Debian, Nlnetlabs | 2 Debian Linux, Unbound | 2024-08-05 | 5.0 MEDIUM | 7.5 HIGH |
| Unbound before 1.9.5 allows an infinite loop via a compressed name in dname_pkt_copy. NOTE: The vendor disputes that this is a vulnerability. Although the code may be vulnerable, a running Unbound installation cannot be remotely or locally exploited | |||||
| CVE-2023-50570 | 1 Seancfoley | 1 Ipaddress | 2024-08-02 | N/A | 5.5 MEDIUM |
| An issue in the component IPAddressBitsDivision of IPAddress v5.1.0 leads to an infinite loop. This is disputed because an infinite loop occurs only for cases in which the developer supplies invalid arguments. The product is not intended to always halt for contrived inputs. | |||||
| CVE-2023-38197 | 1 Qt | 1 Qt | 2024-08-01 | N/A | 7.5 HIGH |
| An issue was discovered in Qt before 5.15.15, 6.x before 6.2.10, and 6.3.x through 6.5.x before 6.5.3. There are infinite loops in recursive entity expansion. | |||||
| CVE-2022-48862 | 1 Linux | 1 Linux Kernel | 2024-07-23 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: vhost: fix hung thread due to erroneous iotlb entries In vhost_iotlb_add_range_ctx(), range size can overflow to 0 when start is 0 and last is ULONG_MAX. One instance where it can happen is when userspace sends an IOTLB message with iova=size=uaddr=0 (vhost_process_iotlb_msg). So, an entry with size = 0, start = 0, last = ULONG_MAX ends up in the iotlb. Next time a packet is sent, iotlb_access_ok() loops indefinitely due to that erroneous entry. Call Trace: <TASK> iotlb_access_ok+0x21b/0x3e0 drivers/vhost/vhost.c:1340 vq_meta_prefetch+0xbc/0x280 drivers/vhost/vhost.c:1366 vhost_transport_do_send_pkt+0xe0/0xfd0 drivers/vhost/vsock.c:104 vhost_worker+0x23d/0x3d0 drivers/vhost/vhost.c:372 kthread+0x2e9/0x3a0 kernel/kthread.c:377 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295 </TASK> Reported by syzbot at: https://syzkaller.appspot.com/bug?extid=0abd373e2e50d704db87 To fix this, do two things: 1. Return -EINVAL in vhost_chr_write_iter() when userspace asks to map a range with size 0. 2. Fix vhost_iotlb_add_range_ctx() to handle the range [0, ULONG_MAX] by splitting it into two entries. | |||||
| CVE-2022-48840 | 1 Linux | 1 Linux Kernel | 2024-07-17 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: iavf: Fix hang during reboot/shutdown Recent commit 974578017fc1 ("iavf: Add waiting so the port is initialized in remove") adds a wait-loop at the beginning of iavf_remove() to ensure that port initialization is finished prior unregistering net device. This causes a regression in reboot/shutdown scenario because in this case callback iavf_shutdown() is called and this callback detaches the device, makes it down if it is running and sets its state to __IAVF_REMOVE. Later shutdown callback of associated PF driver (e.g. ice_shutdown) is called. That callback calls among other things sriov_disable() that calls indirectly iavf_remove() (see stack trace below). As the adapter state is already __IAVF_REMOVE then the mentioned loop is end-less and shutdown process hangs. The patch fixes this by checking adapter's state at the beginning of iavf_remove() and skips the rest of the function if the adapter is already in remove state (shutdown is in progress). Reproducer: 1. Create VF on PF driven by ice or i40e driver 2. Ensure that the VF is bound to iavf driver 3. Reboot [52625.981294] sysrq: SysRq : Show Blocked State [52625.988377] task:reboot state:D stack: 0 pid:17359 ppid: 1 f2 [52625.996732] Call Trace: [52625.999187] __schedule+0x2d1/0x830 [52626.007400] schedule+0x35/0xa0 [52626.010545] schedule_hrtimeout_range_clock+0x83/0x100 [52626.020046] usleep_range+0x5b/0x80 [52626.023540] iavf_remove+0x63/0x5b0 [iavf] [52626.027645] pci_device_remove+0x3b/0xc0 [52626.031572] device_release_driver_internal+0x103/0x1f0 [52626.036805] pci_stop_bus_device+0x72/0xa0 [52626.040904] pci_stop_and_remove_bus_device+0xe/0x20 [52626.045870] pci_iov_remove_virtfn+0xba/0x120 [52626.050232] sriov_disable+0x2f/0xe0 [52626.053813] ice_free_vfs+0x7c/0x340 [ice] [52626.057946] ice_remove+0x220/0x240 [ice] [52626.061967] ice_shutdown+0x16/0x50 [ice] [52626.065987] pci_device_shutdown+0x34/0x60 [52626.070086] device_shutdown+0x165/0x1c5 [52626.074011] kernel_restart+0xe/0x30 [52626.077593] __do_sys_reboot+0x1d2/0x210 [52626.093815] do_syscall_64+0x5b/0x1a0 [52626.097483] entry_SYSCALL_64_after_hwframe+0x65/0xca | |||||
| CVE-2022-0778 | 7 Debian, Fedoraproject, Mariadb and 4 more | 15 Debian Linux, Fedora, Mariadb and 12 more | 2024-06-21 | 5.0 MEDIUM | 7.5 HIGH |
| The BN_mod_sqrt() function, which computes a modular square root, contains a bug that can cause it to loop forever for non-prime moduli. Internally this function is used when parsing certificates that contain elliptic curve public keys in compressed form or explicit elliptic curve parameters with a base point encoded in compressed form. It is possible to trigger the infinite loop by crafting a certificate that has invalid explicit curve parameters. Since certificate parsing happens prior to verification of the certificate signature, any process that parses an externally supplied certificate may thus be subject to a denial of service attack. The infinite loop can also be reached when parsing crafted private keys as they can contain explicit elliptic curve parameters. Thus vulnerable situations include: - TLS clients consuming server certificates - TLS servers consuming client certificates - Hosting providers taking certificates or private keys from customers - Certificate authorities parsing certification requests from subscribers - Anything else which parses ASN.1 elliptic curve parameters Also any other applications that use the BN_mod_sqrt() where the attacker can control the parameter values are vulnerable to this DoS issue. In the OpenSSL 1.0.2 version the public key is not parsed during initial parsing of the certificate which makes it slightly harder to trigger the infinite loop. However any operation which requires the public key from the certificate will trigger the infinite loop. In particular the attacker can use a self-signed certificate to trigger the loop during verification of the certificate signature. This issue affects OpenSSL versions 1.0.2, 1.1.1 and 3.0. It was addressed in the releases of 1.1.1n and 3.0.2 on the 15th March 2022. Fixed in OpenSSL 3.0.2 (Affected 3.0.0,3.0.1). Fixed in OpenSSL 1.1.1n (Affected 1.1.1-1.1.1m). Fixed in OpenSSL 1.0.2zd (Affected 1.0.2-1.0.2zc). | |||||
| CVE-2024-32976 | 1 Envoyproxy | 1 Envoy | 2024-06-12 | N/A | 7.5 HIGH |
| Envoy is a cloud-native, open source edge and service proxy. Envoyproxy with a Brotli filter can get into an endless loop during decompression of Brotli data with extra input. | |||||