Total
2909 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2019-9514 | 13 Apache, Apple, Canonical and 10 more | 44 Traffic Server, Mac Os X, Swiftnio and 41 more | 2025-01-14 | 7.5 High |
| Some HTTP/2 implementations are vulnerable to a reset flood, potentially leading to a denial of service. The attacker opens a number of streams and sends an invalid request over each stream that should solicit a stream of RST_STREAM frames from the peer. Depending on how the peer queues the RST_STREAM frames, this can consume excess memory, CPU, or both. | ||||
| CVE-2019-9515 | 12 Apache, Apple, Canonical and 9 more | 36 Traffic Server, Mac Os X, Swiftnio and 33 more | 2025-01-14 | 7.5 High |
| Some HTTP/2 implementations are vulnerable to a settings flood, potentially leading to a denial of service. The attacker sends a stream of SETTINGS frames to the peer. Since the RFC requires that the peer reply with one acknowledgement per SETTINGS frame, an empty SETTINGS frame is almost equivalent in behavior to a ping. Depending on how efficiently this data is queued, this can consume excess CPU, memory, or both. | ||||
| CVE-2019-9516 | 12 Apache, Apple, Canonical and 9 more | 24 Traffic Server, Mac Os X, Swiftnio and 21 more | 2025-01-14 | 6.5 Medium |
| Some HTTP/2 implementations are vulnerable to a header leak, potentially leading to a denial of service. The attacker sends a stream of headers with a 0-length header name and 0-length header value, optionally Huffman encoded into 1-byte or greater headers. Some implementations allocate memory for these headers and keep the allocation alive until the session dies. This can consume excess memory. | ||||
| CVE-2019-9517 | 12 Apache, Apple, Canonical and 9 more | 28 Http Server, Traffic Server, Mac Os X and 25 more | 2025-01-14 | 7.5 High |
| Some HTTP/2 implementations are vulnerable to unconstrained interal data buffering, potentially leading to a denial of service. The attacker opens the HTTP/2 window so the peer can send without constraint; however, they leave the TCP window closed so the peer cannot actually write (many of) the bytes on the wire. The attacker then sends a stream of requests for a large response object. Depending on how the servers queue the responses, this can consume excess memory, CPU, or both. | ||||
| CVE-2023-30570 | 2 Libreswan, Redhat | 6 Libreswan, Enterprise Linux, Rhel Aus and 3 more | 2025-01-14 | 7.5 High |
| pluto in Libreswan before 4.11 allows a denial of service (responder SPI mishandling and daemon crash) via unauthenticated IKEv1 Aggressive Mode packets. The earliest affected version is 3.28. | ||||
| CVE-2023-29735 | 1 Mwm | 1 Edjing Mix | 2025-01-14 | 5.5 Medium |
| An issue found in edjing Mix v.7.09.01 for Android allows a local attacker to cause a denial of service via the database files. | ||||
| CVE-2022-25622 | 1 Siemens | 23 Simatic Cfu Diq, Simatic Cfu Diq Firmware, Simatic Cfu Pa and 20 more | 2025-01-14 | 5.3 Medium |
| The PROFINET (PNIO) stack, when integrated with the Interniche IP stack, improperly handles internal resources for TCP segments where the minimum TCP-Header length is less than defined. This could allow an attacker to create a denial of service condition for TCP services on affected devices by sending specially crafted TCP segments. | ||||
| CVE-2019-19300 | 1 Siemens | 65 Ktk Ate530s, Ktk Ate530s Firmware, Sidoor Atd430w and 62 more | 2025-01-14 | 7.5 High |
| A vulnerability has been identified in Development/Evaluation Kits for PROFINET IO: EK-ERTEC 200, Development/Evaluation Kits for PROFINET IO: EK-ERTEC 200P, KTK ATE530S, SIDOOR ATD430W, SIDOOR ATE530S COATED, SIDOOR ATE531S, SIMATIC ET 200AL IM 157-1 PN (6ES7157-1AB00-0AB0), SIMATIC ET 200MP IM 155-5 PN HF (6ES7155-5AA00-0AC0), SIMATIC ET 200pro IM 154-8 PN/DP CPU (6ES7154-8AB01-0AB0), SIMATIC ET 200pro IM 154-8F PN/DP CPU (6ES7154-8FB01-0AB0), SIMATIC ET 200pro IM 154-8FX PN/DP CPU (6ES7154-8FX00-0AB0), SIMATIC ET 200S IM 151-8 PN/DP CPU (6ES7151-8AB01-0AB0), SIMATIC ET 200S IM 151-8F PN/DP CPU (6ES7151-8FB01-0AB0), SIMATIC ET 200SP IM 155-6 MF HF (6ES7155-6MU00-0CN0), SIMATIC ET 200SP IM 155-6 PN HA (incl. SIPLUS variants), SIMATIC ET 200SP IM 155-6 PN HF (6ES7155-6AU00-0CN0), SIMATIC ET 200SP IM 155-6 PN/2 HF (6ES7155-6AU01-0CN0), SIMATIC ET 200SP IM 155-6 PN/3 HF (6ES7155-6AU30-0CN0), SIMATIC ET 200SP Open Controller CPU 1515SP PC (incl. SIPLUS variants), SIMATIC ET 200SP Open Controller CPU 1515SP PC2 (incl. SIPLUS variants), SIMATIC ET200ecoPN, AI 8xRTD/TC, M12-L (6ES7144-6JF00-0BB0), SIMATIC ET200ecoPN, CM 4x IO-Link, M12-L (6ES7148-6JE00-0BB0), SIMATIC ET200ecoPN, CM 8x IO-Link, M12-L (6ES7148-6JG00-0BB0), SIMATIC ET200ecoPN, CM 8x IO-Link, M12-L (6ES7148-6JJ00-0BB0), SIMATIC ET200ecoPN, DI 16x24VDC, M12-L (6ES7141-6BH00-0BB0), SIMATIC ET200ecoPN, DI 8x24VDC, M12-L (6ES7141-6BG00-0BB0), SIMATIC ET200ecoPN, DIQ 16x24VDC/2A, M12-L (6ES7143-6BH00-0BB0), SIMATIC ET200ecoPN, DQ 8x24VDC/0,5A, M12-L (6ES7142-6BG00-0BB0), SIMATIC ET200ecoPN, DQ 8x24VDC/2A, M12-L (6ES7142-6BR00-0BB0), SIMATIC MICRO-DRIVE PDC, SIMATIC PN/MF Coupler (6ES7158-3MU10-0XA0), SIMATIC PN/PN Coupler (6ES7158-3AD10-0XA0), SIMATIC S7-1200 CPU family (incl. SIPLUS variants), SIMATIC S7-1500 CPU family (incl. related ET200 CPUs and SIPLUS variants), SIMATIC S7-1500 Software Controller, SIMATIC S7-300 CPU 314C-2 PN/DP (6ES7314-6EH04-0AB0), SIMATIC S7-300 CPU 315-2 PN/DP (6ES7315-2EH14-0AB0), SIMATIC S7-300 CPU 315F-2 PN/DP (6ES7315-2FJ14-0AB0), SIMATIC S7-300 CPU 315T-3 PN/DP (6ES7315-7TJ10-0AB0), SIMATIC S7-300 CPU 317-2 PN/DP (6ES7317-2EK14-0AB0), SIMATIC S7-300 CPU 317F-2 PN/DP (6ES7317-2FK14-0AB0), SIMATIC S7-300 CPU 317T-3 PN/DP (6ES7317-7TK10-0AB0), SIMATIC S7-300 CPU 317TF-3 PN/DP (6ES7317-7UL10-0AB0), SIMATIC S7-300 CPU 319-3 PN/DP (6ES7318-3EL01-0AB0), SIMATIC S7-300 CPU 319F-3 PN/DP (6ES7318-3FL01-0AB0), SIMATIC S7-400 H V6 and below CPU family (incl. SIPLUS variants), SIMATIC S7-400 PN/DP V7 CPU family (incl. SIPLUS variants), SIMATIC S7-410 V10 CPU family (incl. SIPLUS variants), SIMATIC S7-410 V8 CPU family (incl. SIPLUS variants), SIMATIC TDC CP51M1, SIMATIC TDC CPU555, SIMATIC WinAC RTX 2010 (6ES7671-0RC08-0YA0), SIMATIC WinAC RTX F 2010 (6ES7671-1RC08-0YA0), SINAMICS S/G Control Unit w. PROFINET, SIPLUS ET 200MP IM 155-5 PN HF (6AG1155-5AA00-2AC0), SIPLUS ET 200MP IM 155-5 PN HF (6AG1155-5AA00-7AC0), SIPLUS ET 200MP IM 155-5 PN HF T1 RAIL (6AG2155-5AA00-1AC0), SIPLUS ET 200S IM 151-8 PN/DP CPU (6AG1151-8AB01-7AB0), SIPLUS ET 200S IM 151-8F PN/DP CPU (6AG1151-8FB01-2AB0), SIPLUS ET 200SP IM 155-6 PN HF (6AG1155-6AU00-2CN0), SIPLUS ET 200SP IM 155-6 PN HF (6AG1155-6AU00-4CN0), SIPLUS ET 200SP IM 155-6 PN HF (6AG1155-6AU01-2CN0), SIPLUS ET 200SP IM 155-6 PN HF (6AG1155-6AU01-7CN0), SIPLUS ET 200SP IM 155-6 PN HF T1 RAIL (6AG2155-6AU00-1CN0), SIPLUS ET 200SP IM 155-6 PN HF T1 RAIL (6AG2155-6AU01-1CN0), SIPLUS ET 200SP IM 155-6 PN HF TX RAIL (6AG2155-6AU01-4CN0), SIPLUS NET PN/PN Coupler (6AG2158-3AD10-4XA0), SIPLUS S7-300 CPU 314C-2 PN/DP (6AG1314-6EH04-7AB0), SIPLUS S7-300 CPU 315-2 PN/DP (6AG1315-2EH14-7AB0), SIPLUS S7-300 CPU 315F-2 PN/DP (6AG1315-2FJ14-2AB0), SIPLUS S7-300 CPU 317-2 PN/DP (6AG1317-2EK14-7AB0), SIPLUS S7-300 CPU 317F-2 PN/DP (6AG1317-2FK14-2AB0). The Interniche-based TCP Stack can be forced to make very expensive calls for every incoming packet which can lead to a denial of service. | ||||
| CVE-2024-8939 | 1 Redhat | 1 Enterprise Linux Ai | 2025-01-14 | 6.2 Medium |
| A vulnerability was found in the ilab model serve component, where improper handling of the best_of parameter in the vllm JSON web API can lead to a Denial of Service (DoS). The API used for LLM-based sentence or chat completion accepts a best_of parameter to return the best completion from several options. When this parameter is set to a large value, the API does not handle timeouts or resource exhaustion properly, allowing an attacker to cause a DoS by consuming excessive system resources. This leads to the API becoming unresponsive, preventing legitimate users from accessing the service. | ||||
| CVE-2022-48639 | 1 Linux | 1 Linux Kernel | 2025-01-13 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: net: sched: fix possible refcount leak in tc_new_tfilter() tfilter_put need to be called to put the refount got by tp->ops->get to avoid possible refcount leak when chain->tmplt_ops != NULL and chain->tmplt_ops != tp->ops. | ||||
| CVE-2023-29544 | 1 Mozilla | 2 Firefox, Focus | 2025-01-10 | 6.5 Medium |
| If multiple instances of resource exhaustion occurred at the incorrect time, the garbage collector could have caused memory corruption and a potentially exploitable crash. This vulnerability affects Firefox for Android < 112, Firefox < 112, and Focus for Android < 112. | ||||
| CVE-2023-0616 | 2 Mozilla, Redhat | 6 Thunderbird, Enterprise Linux, Rhel Aus and 3 more | 2025-01-10 | 6.5 Medium |
| If a MIME email combines OpenPGP and OpenPGP MIME data in a certain way Thunderbird repeatedly attempts to process and display the message, which could cause Thunderbird's user interface to lock up and no longer respond to the user's actions. An attacker could send a crafted message with this structure to attempt a DoS attack. This vulnerability affects Thunderbird < 102.8. | ||||
| CVE-2024-35795 | 2 Linux, Redhat | 2 Linux Kernel, Enterprise Linux | 2025-01-10 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix deadlock while reading mqd from debugfs An errant disk backup on my desktop got into debugfs and triggered the following deadlock scenario in the amdgpu debugfs files. The machine also hard-resets immediately after those lines are printed (although I wasn't able to reproduce that part when reading by hand): [ 1318.016074][ T1082] ====================================================== [ 1318.016607][ T1082] WARNING: possible circular locking dependency detected [ 1318.017107][ T1082] 6.8.0-rc7-00015-ge0c8221b72c0 #17 Not tainted [ 1318.017598][ T1082] ------------------------------------------------------ [ 1318.018096][ T1082] tar/1082 is trying to acquire lock: [ 1318.018585][ T1082] ffff98c44175d6a0 (&mm->mmap_lock){++++}-{3:3}, at: __might_fault+0x40/0x80 [ 1318.019084][ T1082] [ 1318.019084][ T1082] but task is already holding lock: [ 1318.020052][ T1082] ffff98c4c13f55f8 (reservation_ww_class_mutex){+.+.}-{3:3}, at: amdgpu_debugfs_mqd_read+0x6a/0x250 [amdgpu] [ 1318.020607][ T1082] [ 1318.020607][ T1082] which lock already depends on the new lock. [ 1318.020607][ T1082] [ 1318.022081][ T1082] [ 1318.022081][ T1082] the existing dependency chain (in reverse order) is: [ 1318.023083][ T1082] [ 1318.023083][ T1082] -> #2 (reservation_ww_class_mutex){+.+.}-{3:3}: [ 1318.024114][ T1082] __ww_mutex_lock.constprop.0+0xe0/0x12f0 [ 1318.024639][ T1082] ww_mutex_lock+0x32/0x90 [ 1318.025161][ T1082] dma_resv_lockdep+0x18a/0x330 [ 1318.025683][ T1082] do_one_initcall+0x6a/0x350 [ 1318.026210][ T1082] kernel_init_freeable+0x1a3/0x310 [ 1318.026728][ T1082] kernel_init+0x15/0x1a0 [ 1318.027242][ T1082] ret_from_fork+0x2c/0x40 [ 1318.027759][ T1082] ret_from_fork_asm+0x11/0x20 [ 1318.028281][ T1082] [ 1318.028281][ T1082] -> #1 (reservation_ww_class_acquire){+.+.}-{0:0}: [ 1318.029297][ T1082] dma_resv_lockdep+0x16c/0x330 [ 1318.029790][ T1082] do_one_initcall+0x6a/0x350 [ 1318.030263][ T1082] kernel_init_freeable+0x1a3/0x310 [ 1318.030722][ T1082] kernel_init+0x15/0x1a0 [ 1318.031168][ T1082] ret_from_fork+0x2c/0x40 [ 1318.031598][ T1082] ret_from_fork_asm+0x11/0x20 [ 1318.032011][ T1082] [ 1318.032011][ T1082] -> #0 (&mm->mmap_lock){++++}-{3:3}: [ 1318.032778][ T1082] __lock_acquire+0x14bf/0x2680 [ 1318.033141][ T1082] lock_acquire+0xcd/0x2c0 [ 1318.033487][ T1082] __might_fault+0x58/0x80 [ 1318.033814][ T1082] amdgpu_debugfs_mqd_read+0x103/0x250 [amdgpu] [ 1318.034181][ T1082] full_proxy_read+0x55/0x80 [ 1318.034487][ T1082] vfs_read+0xa7/0x360 [ 1318.034788][ T1082] ksys_read+0x70/0xf0 [ 1318.035085][ T1082] do_syscall_64+0x94/0x180 [ 1318.035375][ T1082] entry_SYSCALL_64_after_hwframe+0x46/0x4e [ 1318.035664][ T1082] [ 1318.035664][ T1082] other info that might help us debug this: [ 1318.035664][ T1082] [ 1318.036487][ T1082] Chain exists of: [ 1318.036487][ T1082] &mm->mmap_lock --> reservation_ww_class_acquire --> reservation_ww_class_mutex [ 1318.036487][ T1082] [ 1318.037310][ T1082] Possible unsafe locking scenario: [ 1318.037310][ T1082] [ 1318.037838][ T1082] CPU0 CPU1 [ 1318.038101][ T1082] ---- ---- [ 1318.038350][ T1082] lock(reservation_ww_class_mutex); [ 1318.038590][ T1082] lock(reservation_ww_class_acquire); [ 1318.038839][ T1082] lock(reservation_ww_class_mutex); [ 1318.039083][ T1082] rlock(&mm->mmap_lock); [ 1318.039328][ T1082] [ 1318.039328][ T1082] *** DEADLOCK *** [ 1318.039328][ T1082] [ 1318.040029][ T1082] 1 lock held by tar/1082: [ 1318.040259][ T1082] #0: ffff98c4c13f55f8 (reservation_ww_class_mutex){+.+.}-{3:3}, at: amdgpu_debugfs_mqd_read+0x6a/0x250 [amdgpu] [ 1318.040560][ T1082] [ 1318.040560][ T1082] stack backtrace: [ ---truncated--- | ||||
| CVE-2024-24988 | 1 Mattermost | 1 Mattermost Server | 2025-01-10 | 4.3 Medium |
| Mattermost fails to properly validate the length of the emoji value in the custom user status, allowing an attacker to send multiple times a very long string as an emoji value causing high resource consumption and possibly crashing the server. | ||||
| CVE-2024-55553 | 2025-01-09 | 7.5 High | ||
| In FRRouting (FRR) before 10.3 from 6.0 onward, all routes are re-validated if the total size of an update received via RTR exceeds the internal socket's buffer size, default 4K on most OSes. An attacker can use this to trigger re-parsing of the RIB for FRR routers using RTR by causing more than this number of updates during an update interval (usually 30 minutes). Additionally, this effect regularly occurs organically. Furthermore, an attacker can use this to trigger route validation continuously. Given that routers with large full tables may need more than 30 minutes to fully re-validate the table, continuous issuance/withdrawal of large numbers of ROA may be used to impact the route handling performance of all FRR instances using RPKI globally. Additionally, the re-validation will cause heightened BMP traffic to ingestors. Affected Versions: FRRouting <6.0. Fixed Versions: 10.0.3, 10.1.2, 10.2.1, >= 10.3. | ||||
| CVE-2021-47037 | 1 Linux | 1 Linux Kernel | 2025-01-09 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: ASoC: q6afe-clocks: fix reprobing of the driver Q6afe-clocks driver can get reprobed. For example if the APR services are restarted after the firmware crash. However currently Q6afe-clocks driver will oops because hw.init will get cleared during first _probe call. Rewrite the driver to fill the clock data at runtime rather than using big static array of clocks. | ||||
| CVE-2024-10466 | 2 Mozilla, Redhat | 9 Firefox, Firefox Esr, Thunderbird and 6 more | 2025-01-09 | 7.5 High |
| By sending a specially crafted push message, a remote server could have hung the parent process, causing the browser to become unresponsive. This vulnerability affects Firefox < 132, Firefox ESR < 128.4, Thunderbird < 128.4, and Thunderbird < 132. | ||||
| CVE-2024-32476 | 1 Argoproj | 1 Argo Cd | 2025-01-09 | 6.5 Medium |
| Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes. There is a Denial of Service (DoS) vulnerability via OOM using jq in ignoreDifferences. This vulnerability has been patched in version(s) 2.10.7, 2.9.12 and 2.8.16. | ||||
| CVE-2024-40634 | 2 Argoproj, Redhat | 3 Argo-cd, Argo Cd, Openshift Gitops | 2025-01-09 | 7.5 High |
| Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes. This report details a security vulnerability in Argo CD, where an unauthenticated attacker can send a specially crafted large JSON payload to the /api/webhook endpoint, causing excessive memory allocation that leads to service disruption by triggering an Out Of Memory (OOM) kill. The issue poses a high risk to the availability of Argo CD deployments. This vulnerability is fixed in 2.11.6, 2.10.15, and 2.9.20. | ||||
| CVE-2024-29893 | 2 Argoproj, Redhat | 2 Argo Cd, Openshift Gitops | 2025-01-09 | 6.5 Medium |
| Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes. All versions of ArgoCD starting from v2.4 have a bug where the ArgoCD repo-server component is vulnerable to a Denial-of-Service attack vector. Specifically, it's possible to crash the repo server component through an out of memory error by pointing it to a malicious Helm registry. The loadRepoIndex() function in the ArgoCD's helm package, does not limit the size nor time while fetching the data. It fetches it and creates a byte slice from the retrieved data in one go. If the registry is implemented to push data continuously, the repo server will keep allocating memory until it runs out of it. A patch for this vulnerability has been released in v2.10.3, v2.9.8, and v2.8.12. | ||||