| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| 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. |
| 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. |
| A vulnerability in the multicast DNS (mDNS) gateway feature of Cisco IOS XE Software for Wireless LAN Controllers (WLCs) could allow an unauthenticated, adjacent attacker to cause a denial of service (DoS) condition.
This vulnerability is due to improper management of mDNS client entries. An attacker could exploit this vulnerability by connecting to the wireless network and sending a continuous stream of specific mDNS packets. A successful exploit could allow the attacker to cause the wireless controller to have high CPU utilization, which could lead to access points (APs) losing their connection to the controller and result in a DoS condition. |
| In NetX HTTP server functionality of Eclipse ThreadX NetX Duo before
version 6.4.2, an attacker can cause a denial of service by specially
crafted packets. The core issue is missing closing of a file in case of
an error condition, resulting in the 404 error for each further file
request. Users can work-around the issue by disabling the PUT request
support. |
| In NetX HTTP server functionality of Eclipse ThreadX NetX Duo before
version 6.4.3, an attacker can cause a denial of service by specially
crafted packets. The core issue is missing closing of a file in case of
an error condition, resulting in the 404 error for each further file
request. Users can work-around the issue by disabling the PUT request
support.
This issue follows an incomplete fix of CVE-2025-0726. |
| 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. |
| In the Linux kernel, the following vulnerability has been resolved:
scsi: hisi_sas: Free irq vectors in order for v3 HW
If the driver probe fails to request the channel IRQ or fatal IRQ, the
driver will free the IRQ vectors before freeing the IRQs in free_irq(),
and this will cause a kernel BUG like this:
------------[ cut here ]------------
kernel BUG at drivers/pci/msi.c:369!
Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
Call trace:
free_msi_irqs+0x118/0x13c
pci_disable_msi+0xfc/0x120
pci_free_irq_vectors+0x24/0x3c
hisi_sas_v3_probe+0x360/0x9d0 [hisi_sas_v3_hw]
local_pci_probe+0x44/0xb0
work_for_cpu_fn+0x20/0x34
process_one_work+0x1d0/0x340
worker_thread+0x2e0/0x460
kthread+0x180/0x190
ret_from_fork+0x10/0x20
---[ end trace b88990335b610c11 ]---
So we use devm_add_action() to control the order in which we free the
vectors. |
| IBOS v4.5.5 has an arbitrary file deletion vulnerability via \system\modules\dashboard\controllers\LoginController.php. |
| Tunnelblick 3.5beta06 before 7.0, when incompletely uninstalled, allows attackers to execute arbitrary code as root (upon the next boot) by dragging a crafted Tunnelblick.app file into /Applications. |
| In the Linux kernel, the following vulnerability has been resolved:
posix-cpu-timers: Cleanup CPU timers before freeing them during exec
Commit 55e8c8eb2c7b ("posix-cpu-timers: Store a reference to a pid not a
task") started looking up tasks by PID when deleting a CPU timer.
When a non-leader thread calls execve, it will switch PIDs with the leader
process. Then, as it calls exit_itimers, posix_cpu_timer_del cannot find
the task because the timer still points out to the old PID.
That means that armed timers won't be disarmed, that is, they won't be
removed from the timerqueue_list. exit_itimers will still release their
memory, and when that list is later processed, it leads to a
use-after-free.
Clean up the timers from the de-threaded task before freeing them. This
prevents a reported use-after-free. |
|
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.
|
| 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. |
| In the Linux kernel, the following vulnerability has been resolved:
x86/kvm: Teardown PV features on boot CPU as well
Various PV features (Async PF, PV EOI, steal time) work through memory
shared with hypervisor and when we restore from hibernation we must
properly teardown all these features to make sure hypervisor doesn't
write to stale locations after we jump to the previously hibernated kernel
(which can try to place anything there). For secondary CPUs the job is
already done by kvm_cpu_down_prepare(), register syscore ops to do
the same for boot CPU. |
| In the Linux kernel, the following vulnerability has been resolved:
x86/kvm: Disable kvmclock on all CPUs on shutdown
Currenly, we disable kvmclock from machine_shutdown() hook and this
only happens for boot CPU. We need to disable it for all CPUs to
guard against memory corruption e.g. on restore from hibernate.
Note, writing '0' to kvmclock MSR doesn't clear memory location, it
just prevents hypervisor from updating the location so for the short
while after write and while CPU is still alive, the clock remains usable
and correct so we don't need to switch to some other clocksource. |
| In the Linux kernel, the following vulnerability has been resolved:
s390/pkey: Wipe copies of clear-key structures on failure
Wipe all sensitive data from stack for all IOCTLs, which convert a
clear-key into a protected- or secure-key. |
| Information disclosure due to exposure of information while GPU reads the data in Snapdragon Auto, Snapdragon Compute, Snapdragon Connectivity, Snapdragon Consumer IOT, Snapdragon Industrial IOT, Snapdragon Mobile, Snapdragon Wearables |
| SiYuan is self-hosted, open source personal knowledge management software. SiYuan Note version 3.1.18 has an arbitrary file deletion vulnerability. The vulnerability exists in the `POST /api/history/getDocHistoryContent` endpoint. An attacker can craft a payload to exploit this vulnerability, resulting in the deletion of arbitrary files on the server. Commit d9887aeec1b27073bec66299a9a4181dc42969f3 fixes this vulnerability and is expected to be available in version 3.1.19. |
| In the Linux kernel, the following vulnerability has been resolved:
binder: make sure fd closes complete
During BC_FREE_BUFFER processing, the BINDER_TYPE_FDA object
cleanup may close 1 or more fds. The close operations are
completed using the task work mechanism -- which means the thread
needs to return to userspace or the file object may never be
dereferenced -- which can lead to hung processes.
Force the binder thread back to userspace if an fd is closed during
BC_FREE_BUFFER handling. |
| In the Linux kernel, the following vulnerability has been resolved:
afs: Fix page leak
There's a loop in afs_extend_writeback() that adds extra pages to a write
we want to make to improve the efficiency of the writeback by making it
larger. This loop stops, however, if we hit a page we can't write back
from immediately, but it doesn't get rid of the page ref we speculatively
acquired.
This was caused by the removal of the cleanup loop when the code switched
from using find_get_pages_contig() to xarray scanning as the latter only
gets a single page at a time, not a batch.
Fix this by putting the page on a ref on an early break from the loop.
Unfortunately, we can't just add that page to the pagevec we're employing
as we'll go through that and add those pages to the RPC call.
This was found by the generic/074 test. It leaks ~4GiB of RAM each time it
is run - which can be observed with "top". |
| In the Linux kernel, the following vulnerability has been resolved:
usb: xhci: Check for xhci->interrupters being allocated in xhci_mem_clearup()
If xhci_mem_init() fails, it calls into xhci_mem_cleanup() to mop
up the damage. If it fails early enough, before xhci->interrupters
is allocated but after xhci->max_interrupters has been set, which
happens in most (all?) cases, things get uglier, as xhci_mem_cleanup()
unconditionally derefences xhci->interrupters. With prejudice.
Gate the interrupt freeing loop with a check on xhci->interrupters
being non-NULL.
Found while debugging a DMA allocation issue that led the XHCI driver
on this exact path. |
