Total
385 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2024-11097 | 2 Razormist, Sourcecodester | 2 Student Record Management System, Student Record Management System | 2024-11-14 | 3.3 Low |
| A vulnerability has been found in SourceCodester Student Record Management System 1.0 and classified as problematic. This vulnerability affects unknown code of the component Main Menu. The manipulation leads to infinite loop. Attacking locally is a requirement. The exploit has been disclosed to the public and may be used. | ||||
| CVE-2024-27527 | 1 Wasm3 Project | 1 Wasm3 | 2024-11-13 | 7.5 High |
| wasm3 139076a is vulnerable to Denial of Service (DoS). | ||||
| CVE-2024-51179 | 1 Open5gs | 1 Open5gs | 2024-11-13 | 7.5 High |
| An issue in Open 5GS v.2.7.1 allows a remote attacker to cause a denial of service via the Network Function Virtualizations (NFVs) such as the User Plane Function (UPF) and the Session Management Function (SMF), The Packet Data Unit (PDU) session establishment process. | ||||
| CVE-2020-3338 | 1 Cisco | 67 Nexus 3016, Nexus 3048, Nexus 3064 and 64 more | 2024-11-13 | 7.5 High |
| A vulnerability in the Protocol Independent Multicast (PIM) feature for IPv6 networks (PIM6) of Cisco NX-OS Software could allow an unauthenticated, remote attacker to cause a denial of service (DoS) condition on an affected device. The vulnerability is due to improper error handling when processing inbound PIM6 packets. An attacker could exploit this vulnerability by sending multiple crafted PIM6 packets to an affected device. A successful exploit could allow the attacker to cause the PIM6 application to leak system memory. Over time, this memory leak could cause the PIM6 application to stop processing legitimate PIM6 traffic, leading to a DoS condition on the affected device. | ||||
| CVE-2020-3555 | 1 Cisco | 3 Adaptive Security Appliance, Adaptive Security Appliance Software, Firepower Threat Defense | 2024-11-13 | 6.8 Medium |
| A vulnerability in the SIP inspection process of Cisco Adaptive Security Appliance (ASA) Software and Cisco Firepower Threat Defense (FTD) Software could allow an unauthenticated, remote attacker to cause a crash and reload of an affected device, resulting in a denial of service (DoS) condition. The vulnerability is due to a watchdog timeout and crash during the cleanup of threads that are associated with a SIP connection that is being deleted from the connection list. An attacker could exploit this vulnerability by sending a high rate of crafted SIP traffic through an affected device. A successful exploit could allow the attacker to cause a watchdog timeout and crash, resulting in a crash and reload of the affected device. | ||||
| CVE-2020-26070 | 1 Cisco | 12 Asr 9000v, Asr 9001, Asr 9006 and 9 more | 2024-11-13 | 8.6 High |
| A vulnerability in the ingress packet processing function of Cisco IOS XR Software for Cisco ASR 9000 Series Aggregation Services Routers could allow an unauthenticated, remote attacker to cause a denial of service (DoS) condition on an affected device. The vulnerability is due to improper resource allocation when an affected device processes network traffic in software switching mode (punted). An attacker could exploit this vulnerability by sending specific streams of Layer 2 or Layer 3 protocol data units (PDUs) to an affected device. A successful exploit could cause the affected device to run out of buffer resources, which could make the device unable to process or forward traffic, resulting in a DoS condition. The device would need to be restarted to regain functionality. | ||||
| CVE-2024-20905 | 2024-11-13 | 2.7 Low | ||
| Vulnerability in the JD Edwards EnterpriseOne Tools product of Oracle JD Edwards (component: Enterprise Infrastructure SEC). Supported versions that are affected are Prior to 9.2.8.0. Easily exploitable vulnerability allows high privileged attacker with network access via JDENET to compromise JD Edwards EnterpriseOne Tools. Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of JD Edwards EnterpriseOne Tools. CVSS 3.1 Base Score 2.7 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:L). | ||||
| CVE-2024-0889 | 1 Kmint21 | 1 Golden Ftp Server | 2024-11-13 | 5.3 Medium |
| A vulnerability was found in Kmint21 Golden FTP Server 2.02b and classified as problematic. This issue affects some unknown processing of the component PASV Command Handler. The manipulation leads to denial of service. The attack may be initiated remotely. The exploit has been disclosed to the public and may be used. The identifier VDB-252041 was assigned to this vulnerability. | ||||
| CVE-2021-40122 | 1 Cisco | 1 Meeting Server | 2024-11-07 | 5.9 Medium |
| A vulnerability in an API of the Call Bridge feature of Cisco Meeting Server could allow an unauthenticated, remote attacker to cause a denial of service (DoS) condition. This vulnerability is due to improper handling of large series of message requests. An attacker could exploit this vulnerability by sending a series of messages to the vulnerable API. A successful exploit could allow the attacker to cause the affected device to reload, dropping all ongoing calls and resulting in a DoS condition. | ||||
| CVE-2024-22019 | 2 Node.js, Redhat | 4 Node.js, Enterprise Linux, Rhel Eus and 1 more | 2024-11-07 | 7.5 High |
| A vulnerability in Node.js HTTP servers allows an attacker to send a specially crafted HTTP request with chunked encoding, leading to resource exhaustion and denial of service (DoS). The server reads an unbounded number of bytes from a single connection, exploiting the lack of limitations on chunk extension bytes. The issue can cause CPU and network bandwidth exhaustion, bypassing standard safeguards like timeouts and body size limits. | ||||
| CVE-2024-20966 | 1 Redhat | 2 Enterprise Linux, Rhel Software Collections | 2024-11-07 | 4.9 Medium |
| Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer). Supported versions that are affected are 8.0.35 and prior and 8.2.0 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H). | ||||
| CVE-2024-23248 | 2024-11-07 | 6.5 Medium | ||
| The issue was addressed with improved memory handling. This issue is fixed in macOS Sonoma 14.4. Processing a file may lead to a denial-of-service or potentially disclose memory contents. | ||||
| CVE-2024-26757 | 1 Redhat | 1 Enterprise Linux | 2024-11-06 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: md: Don't ignore read-only array in md_check_recovery() Usually if the array is not read-write, md_check_recovery() won't register new sync_thread in the first place. And if the array is read-write and sync_thread is registered, md_set_readonly() will unregister sync_thread before setting the array read-only. md/raid follow this behavior hence there is no problem. After commit f52f5c71f3d4 ("md: fix stopping sync thread"), following hang can be triggered by test shell/integrity-caching.sh: 1) array is read-only. dm-raid update super block: rs_update_sbs ro = mddev->ro mddev->ro = 0 -> set array read-write md_update_sb 2) register new sync thread concurrently. 3) dm-raid set array back to read-only: rs_update_sbs mddev->ro = ro 4) stop the array: raid_dtr md_stop stop_sync_thread set_bit(MD_RECOVERY_INTR, &mddev->recovery); md_wakeup_thread_directly(mddev->sync_thread); wait_event(..., !test_bit(MD_RECOVERY_RUNNING, &mddev->recovery)) 5) sync thread done: md_do_sync set_bit(MD_RECOVERY_DONE, &mddev->recovery); md_wakeup_thread(mddev->thread); 6) daemon thread can't unregister sync thread: md_check_recovery if (!md_is_rdwr(mddev) && !test_bit(MD_RECOVERY_NEEDED, &mddev->recovery)) return; -> -> MD_RECOVERY_RUNNING can't be cleared, hence step 4 hang; The root cause is that dm-raid manipulate 'mddev->ro' by itself, however, dm-raid really should stop sync thread before setting the array read-only. Unfortunately, I need to read more code before I can refacter the handler of 'mddev->ro' in dm-raid, hence let's fix the problem the easy way for now to prevent dm-raid regression. | ||||
| CVE-2024-47972 | 2024-11-06 | 4 Medium | ||
| Improper resource management in firmware of some Solidigm DC Products may allow an attacker to potentially control the performance of the resource. | ||||
| CVE-2024-47736 | 1 Linux | 1 Linux Kernel | 2024-11-05 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: erofs: handle overlapped pclusters out of crafted images properly syzbot reported a task hang issue due to a deadlock case where it is waiting for the folio lock of a cached folio that will be used for cache I/Os. After looking into the crafted fuzzed image, I found it's formed with several overlapped big pclusters as below: Ext: logical offset | length : physical offset | length 0: 0.. 16384 | 16384 : 151552.. 167936 | 16384 1: 16384.. 32768 | 16384 : 155648.. 172032 | 16384 2: 32768.. 49152 | 16384 : 537223168.. 537239552 | 16384 ... Here, extent 0/1 are physically overlapped although it's entirely _impossible_ for normal filesystem images generated by mkfs. First, managed folios containing compressed data will be marked as up-to-date and then unlocked immediately (unlike in-place folios) when compressed I/Os are complete. If physical blocks are not submitted in the incremental order, there should be separate BIOs to avoid dependency issues. However, the current code mis-arranges z_erofs_fill_bio_vec() and BIO submission which causes unexpected BIO waits. Second, managed folios will be connected to their own pclusters for efficient inter-queries. However, this is somewhat hard to implement easily if overlapped big pclusters exist. Again, these only appear in fuzzed images so let's simply fall back to temporary short-lived pages for correctness. Additionally, it justifies that referenced managed folios cannot be truncated for now and reverts part of commit 2080ca1ed3e4 ("erofs: tidy up `struct z_erofs_bvec`") for simplicity although it shouldn't be any difference. | ||||
| CVE-2024-43870 | 1 Redhat | 1 Enterprise Linux | 2024-11-05 | 5.1 Medium |
| In the Linux kernel, the following vulnerability has been resolved: perf: Fix event leak upon exit When a task is scheduled out, pending sigtrap deliveries are deferred to the target task upon resume to userspace via task_work. However failures while adding an event's callback to the task_work engine are ignored. And since the last call for events exit happen after task work is eventually closed, there is a small window during which pending sigtrap can be queued though ignored, leaking the event refcount addition such as in the following scenario: TASK A ----- do_exit() exit_task_work(tsk); <IRQ> perf_event_overflow() event->pending_sigtrap = pending_id; irq_work_queue(&event->pending_irq); </IRQ> =========> PREEMPTION: TASK A -> TASK B event_sched_out() event->pending_sigtrap = 0; atomic_long_inc_not_zero(&event->refcount) // FAILS: task work has exited task_work_add(&event->pending_task) [...] <IRQ WORK> perf_pending_irq() // early return: event->oncpu = -1 </IRQ WORK> [...] =========> TASK B -> TASK A perf_event_exit_task(tsk) perf_event_exit_event() free_event() WARN(atomic_long_cmpxchg(&event->refcount, 1, 0) != 1) // leak event due to unexpected refcount == 2 As a result the event is never released while the task exits. Fix this with appropriate task_work_add()'s error handling. | ||||
| CVE-2024-42152 | 2 Linux, Redhat | 3 Linux Kernel, Enterprise Linux, Rhel Eus | 2024-11-05 | 4.7 Medium |
| In the Linux kernel, the following vulnerability has been resolved: nvmet: fix a possible leak when destroy a ctrl during qp establishment In nvmet_sq_destroy we capture sq->ctrl early and if it is non-NULL we know that a ctrl was allocated (in the admin connect request handler) and we need to release pending AERs, clear ctrl->sqs and sq->ctrl (for nvme-loop primarily), and drop the final reference on the ctrl. However, a small window is possible where nvmet_sq_destroy starts (as a result of the client giving up and disconnecting) concurrently with the nvme admin connect cmd (which may be in an early stage). But *before* kill_and_confirm of sq->ref (i.e. the admin connect managed to get an sq live reference). In this case, sq->ctrl was allocated however after it was captured in a local variable in nvmet_sq_destroy. This prevented the final reference drop on the ctrl. Solve this by re-capturing the sq->ctrl after all inflight request has completed, where for sure sq->ctrl reference is final, and move forward based on that. This issue was observed in an environment with many hosts connecting multiple ctrls simoutanuosly, creating a delay in allocating a ctrl leading up to this race window. | ||||
| CVE-2024-42099 | 2024-11-05 | 5.5 Medium | ||
| In the Linux kernel, the following vulnerability has been resolved: s390/dasd: Fix invalid dereferencing of indirect CCW data pointer Fix invalid dereferencing of indirect CCW data pointer in dasd_eckd_dump_sense() that leads to a kernel panic in error cases. When using indirect addressing for DASD CCWs (IDAW) the CCW CDA pointer does not contain the data address itself but a pointer to the IDAL. This needs to be translated from physical to virtual as well before using it. This dereferencing is also used for dasd_page_cache and also fixed although it is very unlikely that this code path ever gets used. | ||||
| CVE-2024-41006 | 1 Linux | 1 Linux Kernel | 2024-11-05 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: netrom: Fix a memory leak in nr_heartbeat_expiry() syzbot reported a memory leak in nr_create() [0]. Commit 409db27e3a2e ("netrom: Fix use-after-free of a listening socket.") added sock_hold() to the nr_heartbeat_expiry() function, where a) a socket has a SOCK_DESTROY flag or b) a listening socket has a SOCK_DEAD flag. But in the case "a," when the SOCK_DESTROY flag is set, the file descriptor has already been closed and the nr_release() function has been called. So it makes no sense to hold the reference count because no one will call another nr_destroy_socket() and put it as in the case "b." nr_connect nr_establish_data_link nr_start_heartbeat nr_release switch (nr->state) case NR_STATE_3 nr->state = NR_STATE_2 sock_set_flag(sk, SOCK_DESTROY); nr_rx_frame nr_process_rx_frame switch (nr->state) case NR_STATE_2 nr_state2_machine() nr_disconnect() nr_sk(sk)->state = NR_STATE_0 sock_set_flag(sk, SOCK_DEAD) nr_heartbeat_expiry switch (nr->state) case NR_STATE_0 if (sock_flag(sk, SOCK_DESTROY) || (sk->sk_state == TCP_LISTEN && sock_flag(sk, SOCK_DEAD))) sock_hold() // ( !!! ) nr_destroy_socket() To fix the memory leak, let's call sock_hold() only for a listening socket. Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) with Syzkaller. [0]: https://syzkaller.appspot.com/bug?extid=d327a1f3b12e1e206c16 | ||||
| CVE-2024-40934 | 1 Linux | 1 Linux Kernel | 2024-11-05 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: HID: logitech-dj: Fix memory leak in logi_dj_recv_switch_to_dj_mode() Fix a memory leak on logi_dj_recv_send_report() error path. | ||||