Search Results (1228 CVEs found)

CVE Vendors Products Updated CVSS v3.1
CVE-2023-50120 1 Gpac 1 Gpac 2025-06-17 5.5 Medium
MP4Box GPAC version 2.3-DEV-rev636-gfbd7e13aa-master was discovered to contain an infinite loop in the function av1_uvlc at media_tools/av_parsers.c. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted MP4 file.
CVE-2020-27618 5 Debian, Gnu, Netapp and 2 more 25 Debian Linux, Glibc, 500f and 22 more 2025-06-09 5.5 Medium
The iconv function in the GNU C Library (aka glibc or libc6) 2.32 and earlier, when processing invalid multi-byte input sequences in IBM1364, IBM1371, IBM1388, IBM1390, and IBM1399 encodings, fails to advance the input state, which could lead to an infinite loop in applications, resulting in a denial of service, a different vulnerability from CVE-2016-10228.
CVE-2020-14525 1 Philips 1 Clinical Collaboration Platform 2025-06-04 3.5 Low
Philips Clinical Collaboration Platform, Versions 12.2.1 and prior, does not neutralize or incorrectly neutralizes user-controllable input before it is placed in output used as a webpage that is served to other users.
CVE-2024-43863 1 Linux 1 Linux Kernel 2025-06-04 5.5 Medium
In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: Fix a deadlock in dma buf fence polling Introduce a version of the fence ops that on release doesn't remove the fence from the pending list, and thus doesn't require a lock to fix poll->fence wait->fence unref deadlocks. vmwgfx overwrites the wait callback to iterate over the list of all fences and update their status, to do that it holds a lock to prevent the list modifcations from other threads. The fence destroy callback both deletes the fence and removes it from the list of pending fences, for which it holds a lock. dma buf polling cb unrefs a fence after it's been signaled: so the poll calls the wait, which signals the fences, which are being destroyed. The destruction tries to acquire the lock on the pending fences list which it can never get because it's held by the wait from which it was called. Old bug, but not a lot of userspace apps were using dma-buf polling interfaces. Fix those, in particular this fixes KDE stalls/deadlock.
CVE-2023-47997 1 Freeimage Project 1 Freeimage 2025-06-03 6.5 Medium
An issue discovered in BitmapAccess.cpp::FreeImage_AllocateBitmap in FreeImage 3.18.0 leads to an infinite loop and allows attackers to cause a denial of service.
CVE-2024-0211 1 Wireshark 1 Wireshark 2025-06-03 7.8 High
DOCSIS dissector crash in Wireshark 4.2.0 allows denial of service via packet injection or crafted capture file
CVE-2023-5770 1 Proofpoint 1 Enterprise Protection 2025-06-03 5.3 Medium
Proofpoint Enterprise Protection contains a vulnerability in the email delivery agent that allows an unauthenticated attacker to inject improperly encoded HTML into the email body of a message through the email subject. The vulnerability is caused by inappropriate encoding when rewriting the email before delivery.This issue affects Proofpoint Enterprise Protection: from 8.20.2 before patch 4809, from 8.20.0 before patch 4805, from 8.18.6 before patch 4804 and all other prior versions.
CVE-2024-11941 1 Drupal 2 Drupal, Drupal Core 2025-06-02 7.5 High
A vulnerability in Drupal Core allows Excessive Allocation.This issue affects Drupal Core: from 10.2.0 before 10.2.2, from 10.1.0 before 10.1.8.
CVE-2024-34006 1 Moodle 1 Moodle 2025-05-30 4.3 Medium
The site log report required additional encoding of event descriptions to ensure any HTML in the content is displayed in plaintext instead of being rendered.
CVE-2025-29918 1 Oisf 1 Suricata 2025-05-29 6.2 Medium
Suricata is a network Intrusion Detection System, Intrusion Prevention System and Network Security Monitoring engine. A PCRE rule can be written that leads to an infinite loop when negated PCRE is used. Packet processing thread becomes stuck in infinite loop limiting visibility and availability in inline mode. This vulnerability is fixed in 7.0.9.
CVE-2025-4052 1 Google 1 Chrome 2025-05-28 9.8 Critical
Inappropriate implementation in DevTools in Google Chrome prior to 136.0.7103.59 allowed a remote attacker who convinced a user to engage in specific UI gestures to bypass discretionary access control via a crafted HTML page. (Chromium security severity: Low)
CVE-2023-6512 3 Debian, Fedoraproject, Google 3 Debian Linux, Fedora, Chrome 2025-05-28 6.5 Medium
Inappropriate implementation in Web Browser UI in Google Chrome prior to 120.0.6099.62 allowed a remote attacker to potentially spoof the contents of an iframe dialog context menu via a crafted HTML page. (Chromium security severity: Low)
CVE-2025-37847 2025-05-26 4.7 Medium
In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix deadlock in ivpu_ms_cleanup() Fix deadlock in ivpu_ms_cleanup() by preventing runtime resume after file_priv->ms_lock is acquired. During a failure in runtime resume, a cold boot is executed, which calls ivpu_ms_cleanup_all(). This function calls ivpu_ms_cleanup() that acquires file_priv->ms_lock and causes the deadlock.
CVE-2025-22030 2025-05-26 5.5 Medium
In the Linux kernel, the following vulnerability has been resolved: mm: zswap: fix crypto_free_acomp() deadlock in zswap_cpu_comp_dead() Currently, zswap_cpu_comp_dead() calls crypto_free_acomp() while holding the per-CPU acomp_ctx mutex. crypto_free_acomp() then holds scomp_lock (through crypto_exit_scomp_ops_async()). On the other hand, crypto_alloc_acomp_node() holds the scomp_lock (through crypto_scomp_init_tfm()), and then allocates memory. If the allocation results in reclaim, we may attempt to hold the per-CPU acomp_ctx mutex. The above dependencies can cause an ABBA deadlock. For example in the following scenario: (1) Task A running on CPU #1: crypto_alloc_acomp_node() Holds scomp_lock Enters reclaim Reads per_cpu_ptr(pool->acomp_ctx, 1) (2) Task A is descheduled (3) CPU #1 goes offline zswap_cpu_comp_dead(CPU #1) Holds per_cpu_ptr(pool->acomp_ctx, 1)) Calls crypto_free_acomp() Waits for scomp_lock (4) Task A running on CPU #2: Waits for per_cpu_ptr(pool->acomp_ctx, 1) // Read on CPU #1 DEADLOCK Since there is no requirement to call crypto_free_acomp() with the per-CPU acomp_ctx mutex held in zswap_cpu_comp_dead(), move it after the mutex is unlocked. Also move the acomp_request_free() and kfree() calls for consistency and to avoid any potential sublte locking dependencies in the future. With this, only setting acomp_ctx fields to NULL occurs with the mutex held. This is similar to how zswap_cpu_comp_prepare() only initializes acomp_ctx fields with the mutex held, after performing all allocations before holding the mutex. Opportunistically, move the NULL check on acomp_ctx so that it takes place before the mutex dereference.
CVE-2021-39140 6 Debian, Fedoraproject, Netapp and 3 more 21 Debian Linux, Fedora, Snapmanager and 18 more 2025-05-23 6.5 Medium
XStream is a simple library to serialize objects to XML and back again. In affected versions this vulnerability may allow a remote attacker to allocate 100% CPU time on the target system depending on CPU type or parallel execution of such a payload resulting in a denial of service only by manipulating the processed input stream. No user is affected, who followed the recommendation to setup XStream's security framework with a whitelist limited to the minimal required types. XStream 1.4.18 uses no longer a blacklist by default, since it cannot be secured for general purpose.
CVE-2022-28886 1 F-secure 5 Cloud Protection For Salesforce, Collaboration Protection, Elements Endpoint Protection and 2 more 2025-05-22 4.3 Medium
A Denial-of-Service vulnerability was discovered in the F-Secure and WithSecure products where aerdl.so/aerdl.dll may go into an infinite loop when unpacking PE files. It is possible that this can crash the scanning engine
CVE-2024-38600 2 Linux, Redhat 2 Linux Kernel, Enterprise Linux 2025-05-21 5.5 Medium
In the Linux kernel, the following vulnerability has been resolved: ALSA: Fix deadlocks with kctl removals at disconnection In snd_card_disconnect(), we set card->shutdown flag at the beginning, call callbacks and do sync for card->power_ref_sleep waiters at the end. The callback may delete a kctl element, and this can lead to a deadlock when the device was in the suspended state. Namely: * A process waits for the power up at snd_power_ref_and_wait() in snd_ctl_info() or read/write() inside card->controls_rwsem. * The system gets disconnected meanwhile, and the driver tries to delete a kctl via snd_ctl_remove*(); it tries to take card->controls_rwsem again, but this is already locked by the above. Since the sleeper isn't woken up, this deadlocks. An easy fix is to wake up sleepers before processing the driver disconnect callbacks but right after setting the card->shutdown flag. Then all sleepers will abort immediately, and the code flows again. So, basically this patch moves the wait_event() call at the right timing. While we're at it, just to be sure, call wait_event_all() instead of wait_event(), although we don't use exclusive events on this queue for now.
CVE-2024-26767 2 Linux, Redhat 2 Linux Kernel, Enterprise Linux 2025-05-21 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-2022-31628 4 Debian, Fedoraproject, Php and 1 more 4 Debian Linux, Fedora, Php and 1 more 2025-05-20 2.3 Low
In PHP versions before 7.4.31, 8.0.24 and 8.1.11, the phar uncompressor code would recursively uncompress "quines" gzip files, resulting in an infinite loop.
CVE-2025-0137 1 Paloaltonetworks 1 Pan-os 2025-05-16 N/A
An improper input neutralization vulnerability in the management web interface of the Palo Alto Networks PAN-OSĀ® software enables a malicious authenticated read-write administrator to impersonate another legitimate authenticated PAN-OS administrator. The attacker must have network access to the management web interface to exploit this issue. You greatly reduce the risk of this issue by restricting access to the management web interface to only trusted internal IP addresses according to our recommended critical deployment guidelines https://live.paloaltonetworks.com/t5/community-blogs/tips-amp-tricks-how-to-secure-the-management-access-of-your-palo/ba-p/464431 .