Total
1620 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2024-52520 | 2024-11-18 | N/A | 5.7 MEDIUM | ||
| Nextcloud Server is a self hosted personal cloud system. Due to a pre-flighted HEAD request, the link reference provider could be tricked into downloading bigger websites than intended, to find open-graph data. It is recommended that the Nextcloud Server is upgraded to 28.0.10 or 29.0.7 and Nextcloud Enterprise Server is upgraded to 27.1.11.8, 28.0.10 or 29.0.7. | |||||
| CVE-2023-20125 | 2024-11-18 | N/A | 8.6 HIGH | ||
| A vulnerability in the local interface of Cisco BroadWorks Network Server could allow an unauthenticated, remote attacker to exhaust system resources, causing a denial of service (DoS) condition. This vulnerability exists because rate limiting does not occur for certain incoming TCP connections. An attacker could exploit this vulnerability by sending a high rate of TCP connections to the server. A successful exploit could allow the attacker to cause TCP connection resources to grow rapidly until the Cisco BroadWorks Network Server becomes unusable. Note: To recover from this vulnerability, either Cisco BroadWorks Network Server software must be restarted or the Cisco BroadWorks Network Server node must be rebooted. For more information, see the section of this advisory. Cisco has released software updates that address this vulnerability. There are no workarounds that address this vulnerability. | |||||
| CVE-2023-39180 | 2024-11-18 | N/A | 4.0 MEDIUM | ||
| A flaw was found within the handling of SMB2_READ commands in the kernel ksmbd module. The issue results from not releasing memory after its effective lifetime. An attacker can leverage this to create a denial-of-service condition on affected installations of Linux. Authentication is not required to exploit this vulnerability, but only systems with ksmbd enabled are vulnerable. | |||||
| CVE-2024-31152 | 1 Level1 | 2 Wbr-6012, Wbr-6012 Firmware | 2024-11-13 | N/A | 7.5 HIGH |
| The LevelOne WBR-6012 router with firmware R0.40e6 is vulnerable to improper resource allocation within its web application, where a series of crafted HTTP requests can cause a reboot. This could lead to network service interruptions. | |||||
| CVE-2024-47535 | 2024-11-13 | N/A | 5.5 MEDIUM | ||
| Netty is an asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients. An unsafe reading of environment file could potentially cause a denial of service in Netty. When loaded on an Windows application, Netty attempts to load a file that does not exist. If an attacker creates such a large file, the Netty application crashes. This vulnerability is fixed in 4.1.115. | |||||
| CVE-2024-48989 | 2024-11-13 | N/A | 7.5 HIGH | ||
| A vulnerability in the PROFINET stack implementation of the IndraDrive (all versions) of Bosch Rexroth allows an attacker to cause a denial of service, rendering the device unresponsive by sending arbitrary UDP messages. | |||||
| CVE-2023-6681 | 3 Fedoraproject, Latchset, Redhat | 6 Fedora, Jwcrypto, Enterprise Linux and 3 more | 2024-11-12 | N/A | 5.3 MEDIUM |
| A vulnerability was found in JWCrypto. This flaw allows an attacker to cause a denial of service (DoS) attack and possible password brute-force and dictionary attacks to be more resource-intensive. This issue can result in a large amount of computational consumption, causing a denial of service attack. | |||||
| CVE-2024-46891 | 2024-11-12 | N/A | 5.3 MEDIUM | ||
| A vulnerability has been identified in SINEC INS (All versions < V1.0 SP2 Update 3). The affected application does not properly restrict the size of generated log files. This could allow an unauthenticated remote attacker to trigger a large amount of logged events to exhaust the system's resources and create a denial of service condition. | |||||
| CVE-2024-6501 | 2024-11-12 | N/A | 3.1 LOW | ||
| A flaw was found in NetworkManager. When a system running NetworkManager with DEBUG logs enabled and an interface eth1 configured with LLDP enabled, a malicious user could inject a malformed LLDP packet. NetworkManager would crash, leading to a denial of service. | |||||
| CVE-2024-6126 | 2024-11-12 | N/A | 3.2 LOW | ||
| A flaw was found in the cockpit package. This flaw allows an authenticated user to kill any process when enabling the pam_env's user_readenv option, which leads to a denial of service (DoS) attack. | |||||
| CVE-2024-10345 | 2024-11-12 | N/A | N/A | ||
| In Helix Core versions prior to 2024.2, an unauthenticated remote Denial of Service (DoS) via the shutdown function was identified. Reported by Karol Wi?sek. | |||||
| CVE-2024-10344 | 2024-11-12 | N/A | N/A | ||
| In Helix Core versions prior to 2024.2, an unauthenticated remote Denial of Service (DoS) via the refuse function was identified. Reported by Karol Wi?sek. | |||||
| CVE-2024-10314 | 2024-11-12 | N/A | N/A | ||
| In Helix Core versions prior to 2024.2, an unauthenticated remote Denial of Service (DoS) via the auto-generation function was identified. Reported by Karol Wi?sek. | |||||
| CVE-2024-6762 | 1 Eclipse | 1 Jetty | 2024-11-08 | N/A | 6.5 MEDIUM |
| Jetty PushSessionCacheFilter can be exploited by unauthenticated users to launch remote DoS attacks by exhausting the server’s memory. | |||||
| CVE-2024-8184 | 1 Eclipse | 1 Jetty | 2024-11-08 | N/A | 6.5 MEDIUM |
| There exists a security vulnerability in Jetty's ThreadLimitHandler.getRemote() which can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack. By repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the server's memory. | |||||
| CVE-2024-49767 | 1 Palletsprojects | 2 Quart, Werkzeug | 2024-11-05 | N/A | 7.5 HIGH |
| Werkzeug is a Web Server Gateway Interface web application library. Applications using `werkzeug.formparser.MultiPartParser` corresponding to a version of Werkzeug prior to 3.0.6 to parse `multipart/form-data` requests (e.g. all flask applications) are vulnerable to a relatively simple but effective resource exhaustion (denial of service) attack. A specifically crafted form submission request can cause the parser to allocate and block 3 to 8 times the upload size in main memory. There is no upper limit; a single upload at 1 Gbit/s can exhaust 32 GB of RAM in less than 60 seconds. Werkzeug version 3.0.6 fixes this issue. | |||||
| CVE-2024-35997 | 1 Linux | 1 Linux Kernel | 2024-11-05 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: HID: i2c-hid: remove I2C_HID_READ_PENDING flag to prevent lock-up The flag I2C_HID_READ_PENDING is used to serialize I2C operations. However, this is not necessary, because I2C core already has its own locking for that. More importantly, this flag can cause a lock-up: if the flag is set in i2c_hid_xfer() and an interrupt happens, the interrupt handler (i2c_hid_irq) will check this flag and return immediately without doing anything, then the interrupt handler will be invoked again in an infinite loop. Since interrupt handler is an RT task, it takes over the CPU and the flag-clearing task never gets scheduled, thus we have a lock-up. Delete this unnecessary flag. | |||||
| CVE-2024-26976 | 2024-11-05 | N/A | 7.0 HIGH | ||
| In the Linux kernel, the following vulnerability has been resolved: KVM: Always flush async #PF workqueue when vCPU is being destroyed Always flush the per-vCPU async #PF workqueue when a vCPU is clearing its completion queue, e.g. when a VM and all its vCPUs is being destroyed. KVM must ensure that none of its workqueue callbacks is running when the last reference to the KVM _module_ is put. Gifting a reference to the associated VM prevents the workqueue callback from dereferencing freed vCPU/VM memory, but does not prevent the KVM module from being unloaded before the callback completes. Drop the misguided VM refcount gifting, as calling kvm_put_kvm() from async_pf_execute() if kvm_put_kvm() flushes the async #PF workqueue will result in deadlock. async_pf_execute() can't return until kvm_put_kvm() finishes, and kvm_put_kvm() can't return until async_pf_execute() finishes: WARNING: CPU: 8 PID: 251 at virt/kvm/kvm_main.c:1435 kvm_put_kvm+0x2d/0x320 [kvm] Modules linked in: vhost_net vhost vhost_iotlb tap kvm_intel kvm irqbypass CPU: 8 PID: 251 Comm: kworker/8:1 Tainted: G W 6.6.0-rc1-e7af8d17224a-x86/gmem-vm #119 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Workqueue: events async_pf_execute [kvm] RIP: 0010:kvm_put_kvm+0x2d/0x320 [kvm] Call Trace: <TASK> async_pf_execute+0x198/0x260 [kvm] process_one_work+0x145/0x2d0 worker_thread+0x27e/0x3a0 kthread+0xba/0xe0 ret_from_fork+0x2d/0x50 ret_from_fork_asm+0x11/0x20 </TASK> ---[ end trace 0000000000000000 ]--- INFO: task kworker/8:1:251 blocked for more than 120 seconds. Tainted: G W 6.6.0-rc1-e7af8d17224a-x86/gmem-vm #119 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/8:1 state:D stack:0 pid:251 ppid:2 flags:0x00004000 Workqueue: events async_pf_execute [kvm] Call Trace: <TASK> __schedule+0x33f/0xa40 schedule+0x53/0xc0 schedule_timeout+0x12a/0x140 __wait_for_common+0x8d/0x1d0 __flush_work.isra.0+0x19f/0x2c0 kvm_clear_async_pf_completion_queue+0x129/0x190 [kvm] kvm_arch_destroy_vm+0x78/0x1b0 [kvm] kvm_put_kvm+0x1c1/0x320 [kvm] async_pf_execute+0x198/0x260 [kvm] process_one_work+0x145/0x2d0 worker_thread+0x27e/0x3a0 kthread+0xba/0xe0 ret_from_fork+0x2d/0x50 ret_from_fork_asm+0x11/0x20 </TASK> If kvm_clear_async_pf_completion_queue() actually flushes the workqueue, then there's no need to gift async_pf_execute() a reference because all invocations of async_pf_execute() will be forced to complete before the vCPU and its VM are destroyed/freed. And that in turn fixes the module unloading bug as __fput() won't do module_put() on the last vCPU reference until the vCPU has been freed, e.g. if closing the vCPU file also puts the last reference to the KVM module. Note that kvm_check_async_pf_completion() may also take the work item off the completion queue and so also needs to flush the work queue, as the work will not be seen by kvm_clear_async_pf_completion_queue(). Waiting on the workqueue could theoretically delay a vCPU due to waiting for the work to complete, but that's a very, very small chance, and likely a very small delay. kvm_arch_async_page_present_queued() unconditionally makes a new request, i.e. will effectively delay entering the guest, so the remaining work is really just: trace_kvm_async_pf_completed(addr, cr2_or_gpa); __kvm_vcpu_wake_up(vcpu); mmput(mm); and mmput() can't drop the last reference to the page tables if the vCPU is still alive, i.e. the vCPU won't get stuck tearing down page tables. Add a helper to do the flushing, specifically to deal with "wakeup all" work items, as they aren't actually work items, i.e. are never placed in a workqueue. Trying to flush a bogus workqueue entry rightly makes __flush_work() complain (kudos to whoever added that sanity check). Note, commit 5f6de5cbebee ("KVM: Prevent module exit until al ---truncated--- | |||||
| CVE-2024-10599 | 1 Tongda2000 | 1 Office Anywhere | 2024-11-04 | 5.0 MEDIUM | 7.5 HIGH |
| A vulnerability, which was classified as problematic, has been found in Tongda OA 2017 up to 11.7. This issue affects some unknown processing of the file /inc/package_static_resources.php. The manipulation leads to resource consumption. The attack may be initiated remotely. The exploit has been disclosed to the public and may be used. | |||||
| CVE-2023-52672 | 2024-11-04 | N/A | 7.0 HIGH | ||
| In the Linux kernel, the following vulnerability has been resolved: pipe: wakeup wr_wait after setting max_usage Commit c73be61cede5 ("pipe: Add general notification queue support") a regression was introduced that would lock up resized pipes under certain conditions. See the reproducer in [1]. The commit resizing the pipe ring size was moved to a different function, doing that moved the wakeup for pipe->wr_wait before actually raising pipe->max_usage. If a pipe was full before the resize occured it would result in the wakeup never actually triggering pipe_write. Set @max_usage and @nr_accounted before waking writers if this isn't a watch queue. [Christian Brauner <brauner@kernel.org>: rewrite to account for watch queues] | |||||