Total
186 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2024-26756 | 1 Linux | 1 Linux Kernel | 2026-06-17 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: md: Don't register sync_thread for reshape directly Currently, if reshape is interrupted, then reassemble the array will register sync_thread directly from pers->run(), in this case 'MD_RECOVERY_RUNNING' is set directly, however, there is no guarantee that md_do_sync() will be executed, hence stop_sync_thread() will hang because 'MD_RECOVERY_RUNNING' can't be cleared. Last patch make sure that md_do_sync() will set MD_RECOVERY_DONE, however, following hang can still be triggered by dm-raid test shell/lvconvert-raid-reshape.sh occasionally: [root@fedora ~]# cat /proc/1982/stack [<0>] stop_sync_thread+0x1ab/0x270 [md_mod] [<0>] md_frozen_sync_thread+0x5c/0xa0 [md_mod] [<0>] raid_presuspend+0x1e/0x70 [dm_raid] [<0>] dm_table_presuspend_targets+0x40/0xb0 [dm_mod] [<0>] __dm_destroy+0x2a5/0x310 [dm_mod] [<0>] dm_destroy+0x16/0x30 [dm_mod] [<0>] dev_remove+0x165/0x290 [dm_mod] [<0>] ctl_ioctl+0x4bb/0x7b0 [dm_mod] [<0>] dm_ctl_ioctl+0x11/0x20 [dm_mod] [<0>] vfs_ioctl+0x21/0x60 [<0>] __x64_sys_ioctl+0xb9/0xe0 [<0>] do_syscall_64+0xc6/0x230 [<0>] entry_SYSCALL_64_after_hwframe+0x6c/0x74 Meanwhile mddev->recovery is: MD_RECOVERY_RUNNING | MD_RECOVERY_INTR | MD_RECOVERY_RESHAPE | MD_RECOVERY_FROZEN Fix this problem by remove the code to register sync_thread directly from raid10 and raid5. And let md_check_recovery() to register sync_thread. | |||||
| CVE-2024-26687 | 2 Debian, Linux | 2 Debian Linux, Linux Kernel | 2026-06-17 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: xen/events: close evtchn after mapping cleanup shutdown_pirq and startup_pirq are not taking the irq_mapping_update_lock because they can't due to lock inversion. Both are called with the irq_desc->lock being taking. The lock order, however, is first irq_mapping_update_lock and then irq_desc->lock. This opens multiple races: - shutdown_pirq can be interrupted by a function that allocates an event channel: CPU0 CPU1 shutdown_pirq { xen_evtchn_close(e) __startup_pirq { EVTCHNOP_bind_pirq -> returns just freed evtchn e set_evtchn_to_irq(e, irq) } xen_irq_info_cleanup() { set_evtchn_to_irq(e, -1) } } Assume here event channel e refers here to the same event channel number. After this race the evtchn_to_irq mapping for e is invalid (-1). - __startup_pirq races with __unbind_from_irq in a similar way. Because __startup_pirq doesn't take irq_mapping_update_lock it can grab the evtchn that __unbind_from_irq is currently freeing and cleaning up. In this case even though the event channel is allocated, its mapping can be unset in evtchn_to_irq. The fix is to first cleanup the mappings and then close the event channel. In this way, when an event channel gets allocated it's potential previous evtchn_to_irq mappings are guaranteed to be unset already. This is also the reverse order of the allocation where first the event channel is allocated and then the mappings are setup. On a 5.10 kernel prior to commit 3fcdaf3d7634 ("xen/events: modify internal [un]bind interfaces"), we hit a BUG like the following during probing of NVMe devices. The issue is that during nvme_setup_io_queues, pci_free_irq is called for every device which results in a call to shutdown_pirq. With many nvme devices it's therefore likely to hit this race during boot because there will be multiple calls to shutdown_pirq and startup_pirq are running potentially in parallel. ------------[ cut here ]------------ blkfront: xvda: barrier or flush: disabled; persistent grants: enabled; indirect descriptors: enabled; bounce buffer: enabled kernel BUG at drivers/xen/events/events_base.c:499! invalid opcode: 0000 [#1] SMP PTI CPU: 44 PID: 375 Comm: kworker/u257:23 Not tainted 5.10.201-191.748.amzn2.x86_64 #1 Hardware name: Xen HVM domU, BIOS 4.11.amazon 08/24/2006 Workqueue: nvme-reset-wq nvme_reset_work RIP: 0010:bind_evtchn_to_cpu+0xdf/0xf0 Code: 5d 41 5e c3 cc cc cc cc 44 89 f7 e8 2b 55 ad ff 49 89 c5 48 85 c0 0f 84 64 ff ff ff 4c 8b 68 30 41 83 fe ff 0f 85 60 ff ff ff <0f> 0b 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 0f 1f 44 00 00 RSP: 0000:ffffc9000d533b08 EFLAGS: 00010046 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000006 RDX: 0000000000000028 RSI: 00000000ffffffff RDI: 00000000ffffffff RBP: ffff888107419680 R08: 0000000000000000 R09: ffffffff82d72b00 R10: 0000000000000000 R11: 0000000000000000 R12: 00000000000001ed R13: 0000000000000000 R14: 00000000ffffffff R15: 0000000000000002 FS: 0000000000000000(0000) GS:ffff88bc8b500000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 0000000002610001 CR4: 00000000001706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? show_trace_log_lvl+0x1c1/0x2d9 ? show_trace_log_lvl+0x1c1/0x2d9 ? set_affinity_irq+0xdc/0x1c0 ? __die_body.cold+0x8/0xd ? die+0x2b/0x50 ? do_trap+0x90/0x110 ? bind_evtchn_to_cpu+0xdf/0xf0 ? do_error_trap+0x65/0x80 ? bind_evtchn_to_cpu+0xdf/0xf0 ? exc_invalid_op+0x4e/0x70 ? bind_evtchn_to_cpu+0xdf/0xf0 ? asm_exc_invalid_op+0x12/0x20 ? bind_evtchn_to_cpu+0xdf/0x ---truncated--- | |||||
| CVE-2024-26667 | 1 Linux | 1 Linux Kernel | 2026-06-17 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: drm/msm/dpu: check for valid hw_pp in dpu_encoder_helper_phys_cleanup The commit 8b45a26f2ba9 ("drm/msm/dpu: reserve cdm blocks for writeback in case of YUV output") introduced a smatch warning about another conditional block in dpu_encoder_helper_phys_cleanup() which had assumed hw_pp will always be valid which may not necessarily be true. Lets fix the other conditional block by making sure hw_pp is valid before dereferencing it. Patchwork: https://patchwork.freedesktop.org/patch/574878/ | |||||
| CVE-2024-26005 | 1 Phoenixcontact | 8 Charx Sec-3000, Charx Sec-3000 Firmware, Charx Sec-3050 and 5 more | 2026-06-17 | N/A | 4.8 MEDIUM |
| An unauthenticated remote attacker can gain service level privileges through an incomplete cleanup during service restart after a DoS. | |||||
| CVE-2024-23672 | 3 Apache, Debian, Fedoraproject | 3 Tomcat, Debian Linux, Fedora | 2026-06-17 | N/A | 6.3 MEDIUM |
| Denial of Service via incomplete cleanup vulnerability in Apache Tomcat. It was possible for WebSocket clients to keep WebSocket connections open leading to increased resource consumption.This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.0-M16, from 10.1.0-M1 through 10.1.18, from 9.0.0-M1 through 9.0.85, from 8.5.0 through 8.5.98. Older, EOL versions may also be affected. Users are recommended to upgrade to version 11.0.0-M17, 10.1.19, 9.0.86 or 8.5.99 which fix the issue. | |||||
| CVE-2024-21977 | 2026-06-17 | N/A | 3.2 LOW | ||
| Incomplete cleanup after loading a CPU microcode patch may allow a privileged attacker to degrade the entropy of the RDRAND instruction, potentially resulting in loss of integrity for SEV-SNP guests. | |||||
| CVE-2024-21617 | 1 Juniper | 1 Junos | 2026-06-17 | N/A | 6.5 MEDIUM |
| An Incomplete Cleanup vulnerability in Nonstop active routing (NSR) component of Juniper Networks Junos OS allows an adjacent, unauthenticated attacker to cause memory leak leading to Denial of Service (DoS). On all Junos OS platforms, when NSR is enabled, a BGP flap will cause memory leak. A manual reboot of the system will restore the services. Note: NSR is not supported on the SRX Series and is therefore not affected by this vulnerability. The memory usage can be monitored using the below commands. user@host> show chassis routing-engine no-forwarding user@host> show system memory | no-more This issue affects: Juniper Networks Junos OS * 21.2 versions earlier than 21.2R3-S5; * 21.3 versions earlier than 21.3R3-S4; * 21.4 versions earlier than 21.4R3-S4; * 22.1 versions earlier than 22.1R3-S2; * 22.2 versions earlier than 22.2R3-S2; * 22.3 versions earlier than 22.3R2-S1, 22.3R3; * 22.4 versions earlier than 22.4R1-S2, 22.4R2. This issue does not affect Junos OS versions earlier than 20.4R3-S7. | |||||
| CVE-2024-1048 | 3 Fedoraproject, Gnu, Redhat | 3 Fedora, Grub2, Enterprise Linux | 2026-06-17 | N/A | 3.3 LOW |
| A flaw was found in the grub2-set-bootflag utility of grub2. After the fix of CVE-2019-14865, grub2-set-bootflag will create a temporary file with the new grubenv content and rename it to the original grubenv file. If the program is killed before the rename operation, the temporary file will not be removed and may fill the filesystem when invoked multiple times, resulting in a filesystem out of free inodes or blocks. | |||||
| CVE-2023-52929 | 1 Linux | 1 Linux Kernel | 2026-06-17 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: nvmem: core: fix cleanup after dev_set_name() If dev_set_name() fails, we leak nvmem->wp_gpio as the cleanup does not put this. While a minimal fix for this would be to add the gpiod_put() call, we can do better if we split device_register(), and use the tested nvmem_release() cleanup code by initialising the device early, and putting the device. This results in a slightly larger fix, but results in clear code. Note: this patch depends on "nvmem: core: initialise nvmem->id early" and "nvmem: core: remove nvmem_config wp_gpio". [Srini: Fixed subject line and error code handing with wp_gpio while applying.] | |||||
| CVE-2023-52617 | 2 Debian, Linux | 2 Debian Linux, Linux Kernel | 2026-06-17 | N/A | 4.4 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: PCI: switchtec: Fix stdev_release() crash after surprise hot remove A PCI device hot removal may occur while stdev->cdev is held open. The call to stdev_release() then happens during close or exit, at a point way past switchtec_pci_remove(). Otherwise the last ref would vanish with the trailing put_device(), just before return. At that later point in time, the devm cleanup has already removed the stdev->mmio_mrpc mapping. Also, the stdev->pdev reference was not a counted one. Therefore, in DMA mode, the iowrite32() in stdev_release() will cause a fatal page fault, and the subsequent dma_free_coherent(), if reached, would pass a stale &stdev->pdev->dev pointer. Fix by moving MRPC DMA shutdown into switchtec_pci_remove(), after stdev_kill(). Counting the stdev->pdev ref is now optional, but may prevent future accidents. Reproducible via the script at https://lore.kernel.org/r/20231113212150.96410-1-dns@arista.com | |||||
| CVE-2023-45846 | 2 Apple, Intel | 2 Macos, Power Gadget | 2026-06-17 | N/A | 5.5 MEDIUM |
| Incomplete cleanup in Intel(R) Power Gadget software for macOS all versions may allow an authenticated user to potentially enable denial of service via local access. | |||||
| CVE-2023-42795 | 2 Apache, Debian | 2 Tomcat, Debian Linux | 2026-06-17 | N/A | 5.3 MEDIUM |
| Incomplete Cleanup vulnerability in Apache Tomcat.When recycling various internal objects in Apache Tomcat from 11.0.0-M1 through 11.0.0-M11, from 10.1.0-M1 through 10.1.13, from 9.0.0-M1 through 9.0.80 and from 8.5.0 through 8.5.93, an error could cause Tomcat to skip some parts of the recycling process leading to information leaking from the current request/response to the next. Older, EOL versions may also be affected. Users are recommended to upgrade to version 11.0.0-M12 onwards, 10.1.14 onwards, 9.0.81 onwards or 8.5.94 onwards, which fixes the issue. | |||||
| CVE-2023-42794 | 1 Apache | 1 Tomcat | 2026-06-17 | N/A | 5.9 MEDIUM |
| Incomplete Cleanup vulnerability in Apache Tomcat. The internal fork of Commons FileUpload packaged with Apache Tomcat 9.0.70 through 9.0.80 and 8.5.85 through 8.5.93 included an unreleased, in progress refactoring that exposed a potential denial of service on Windows if a web application opened a stream for an uploaded file but failed to close the stream. The file would never be deleted from disk creating the possibility of an eventual denial of service due to the disk being full. Other, EOL versions may also be affected. Users are recommended to upgrade to version 9.0.81 onwards or 8.5.94 onwards, which fixes the issue. | |||||
| CVE-2023-41835 | 1 Apache | 1 Struts | 2026-06-17 | N/A | 7.5 HIGH |
| When a Multipart request is performed but some of the fields exceed the maxStringLength limit, the upload files will remain in struts.multipart.saveDir even if the request has been denied. Users are recommended to upgrade to versions Struts 2.5.32 or 6.1.2.2 or Struts 6.3.0.1 or greater, which fixe this issue. | |||||
| CVE-2023-36468 | 1 Xwiki | 1 Xwiki | 2026-06-17 | N/A | 9.9 CRITICAL |
| XWiki Platform is a generic wiki platform offering runtime services for applications built on top of it. When an XWiki installation is upgraded and that upgrade contains a fix for a bug in a document, just a new version of that document is added. In some cases, it's still possible to exploit the vulnerability that was fixed in the new version. The severity of this depends on the fixed vulnerability, for the purpose of this advisory take CVE-2022-36100/GHSA-2g5c-228j-p52x as example - it is easily exploitable with just view rights and critical. When XWiki is upgraded from a version before the fix for it (e.g., 14.3) to a version including the fix (e.g., 14.4), the vulnerability can still be reproduced by adding `rev=1.1` to the URL used in the reproduction steps so remote code execution is possible even after upgrading. Therefore, this affects the confidentiality, integrity and availability of the whole XWiki installation. This vulnerability also affects manually added script macros that contained security vulnerabilities that were later fixed by changing the script macro without deleting the versions with the security vulnerability from the history. This vulnerability doesn't affect freshly installed versions of XWiki. Further, this vulnerability doesn't affect content that is only loaded from the current version of a document like the code of wiki macros or UI extensions. This vulnerability has been patched in XWiki 14.10.7 and 15.2RC1 by forcing old revisions to be executed in a restricted mode that disables all script macros. As a workaround, admins can manually delete old revisions of affected documents. A script could be used to identify all installed documents and delete the history for them. However, also manually added and later corrected code may be affected by this vulnerability so it is easy to miss documents. | |||||
| CVE-2023-35945 | 2 Envoyproxy, Nghttp2 | 2 Envoy, Nghttp2 | 2026-06-17 | N/A | 7.5 HIGH |
| Envoy is a cloud-native high-performance edge/middle/service proxy. Envoy’s HTTP/2 codec may leak a header map and bookkeeping structures upon receiving `RST_STREAM` immediately followed by the `GOAWAY` frames from an upstream server. In nghttp2, cleanup of pending requests due to receipt of the `GOAWAY` frame skips de-allocation of the bookkeeping structure and pending compressed header. The error return [code path] is taken if connection is already marked for not sending more requests due to `GOAWAY` frame. The clean-up code is right after the return statement, causing memory leak. Denial of service through memory exhaustion. This vulnerability was patched in versions(s) 1.26.3, 1.25.8, 1.24.9, 1.23.11. | |||||
| CVE-2023-31356 | 2026-06-17 | N/A | 4.4 MEDIUM | ||
| Incomplete system memory cleanup in SEV firmware could allow a privileged attacker to corrupt guest private memory, potentially resulting in a loss of data integrity. | |||||
| CVE-2023-2400 | 1 Devolutions | 1 Devolutions Server | 2026-06-17 | N/A | 2.7 LOW |
| Improper deletion of resource in the user management feature in Devolutions Server 2023.1.8 and earlier allows an administrator to view users vaults of deleted users via database access. | |||||
| CVE-2023-29184 | 1 Fortinet | 2 Fortios, Fortiproxy | 2026-06-17 | N/A | 3.2 LOW |
| An incomplete cleanup vulnerability [CWE-459] in FortiOS 7.2 all versions and before & FortiProxy version 7.2.0 through 7.2.2 and before 7.0.8 allows a VDOM privileged attacker to add SSH key files on the system silently via crafted CLI requests. | |||||
| CVE-2023-28859 | 1 Redis | 1 Redis-py | 2026-06-17 | N/A | 6.5 MEDIUM |
| redis-py before 4.4.4 and 4.5.x before 4.5.4 leaves a connection open after canceling an async Redis command at an inopportune time, and can send response data to the client of an unrelated request. (This could, for example, happen for a non-pipeline operation.) NOTE: the solutions for CVE-2023-28859 address data leakage across AsyncIO connections in general. | |||||