| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| 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. |
| 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. |
|
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.
|
| 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. |
| Vulnerability in the PMB platform that allows an attacker to persist temporary files on the server, affecting versions 4.0.10 and above. This vulnerability exists in the file upload functionality on the ‘/pmb/authorities/import/iimport_authorities’ endpoint. When a file is uploaded via this resource, the server will create a temporary file that will be deleted after the client sends a POST request to ‘/pmb/authorities/import/iimport_authorities’. This workflow is automated by the web client, however an attacker can trap and launch the second POST request to prevent the temporary file from being deleted. |
| Incomplete cleanup in a firmware subsystem for Intel(R) SPS before versions SPS_E3_04.08.04.330.0 and SPS_E3_04.01.04.530.0 may allow a privileged user to potentially enable denial of service via local access. |
| Incomplete cleanup in specific special register write operations for some Intel(R) Processors may allow an authenticated user to potentially enable information disclosure via local access. |
| Incomplete cleanup in specific special register read operations for some Intel(R) Processors may allow an authenticated user to potentially enable information disclosure via local access. |
| Incomplete cleanup of microarchitectural fill buffers on some Intel(R) Processors may allow an authenticated user to potentially enable information disclosure via local access. |
| Incomplete cleanup of multi-core shared buffers for some Intel(R) Processors may allow an authenticated user to potentially enable information disclosure via local access. |
