| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In Bouncy Castle for Java FIPS (BC-FJA) before bc-fips 1.0.2.7 (1.0.X series), 2.0.2 (2.0.X series) and 2.1.3 (2.1.X series), sensitive key material held by the AES and DESede engines, the SP 800-90A DRBGs, SymmetricSecretKey and the PBKD and scrypt parameter classes was zeroised on garbage collection by overriding Object.finalize. Finalization runs at an unspecified time and in an unspecified order and is serviced by a single finalizer thread, so where objects carrying a finalizer are allocated faster than that thread retires them the pending-finalization queue grows without bound: disposal falls arbitrarily far behind, which can contribute to an OutOfMemoryError under load, and the key material those objects hold stays resident in the heap for as long as they are queued, defeating the purpose of the zeroisation. The behaviour was not a problem on Java 8 or Java 11; it is later JVMs, on which finalization has been deprecated and progressively de-emphasised, where it becomes one. Disposal of these classes now runs from a java.lang.ref.Cleaner registered in the multi-release jdk1.9 overlay, so on Java 9 and later it no longer depends on the finalizer being scheduled. Bouncy Castle for Java (bcprov) and Bouncy Castle for Java LTS are not affected, as neither implements the finalizer-based zeroisation scheme. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: fix aperture mapping leak
amdgpu_pci_remove() calls drm_dev_unplug() before invoking the driver
fini routines. This causes drm_dev_enter() in amdgpu_ttm_fini() to
always return false, so iounmap(aper_base_kaddr) never runs on normal
driver unload, leaving an orphaned entry in the x86 PAT interval tree.
On connected_to_cpu hardware, the aperture is mapped write-back (WB) via
ioremap_cache(). On reload, IP discovery calls memremap(..., MEMREMAP_WC)
over the same range. The WC vs WB conflict causes:
ioremap error for 0x..., requested 0x1, got 0x0
amdgpu: discovery failed: -2
Fix by switching to devres-managed mappings so cleanup is guaranteed
regardless of drm_dev_enter() state:
- connected_to_cpu path: devm_memremap(MEMREMAP_WB). For
IORESOURCE_SYSTEM_RAM ranges this takes the try_ram_remap() shortcut,
returning __va(offset) from the existing kernel direct map. No new
ioremap VA or PAT entry is created, so there is nothing to orphan.
- dGPU path: devm_ioremap_wc() registers iounmap() as a devres action,
guaranteeing cleanup at device_del() time.
Also remove iounmap(aper_base_kaddr) from amdgpu_device_unmap_mmio()
since the mapping is now devres-owned.
v2: Remove redundant x86_64 guard (Lijo)
(cherry picked from commit d871e99879cb5fd1fa798b006b4888887e63a17a) |
| Netty is an asynchronous, event-driven network application framework. Prior to 4.1.136.Final and 4.2.16.Final, the RedisArrayAggregator Redis codec clears retained partial aggregate state when the maxNestedArrayDepth limit is exceeded, but it does not clear the same state when the sibling maxElements limit is exceeded. A peer can start a valid RESP array, send a bulk string child, then send a nested array header longer than the configured maxElements. Netty throws a decoder exception in decodeRedisArrayHeader, but the existing partial aggregate remains retained in the handler. If the application leaves the channel alive after the exception, later messages are still consumed into the pre-error aggregate, allowing an unauthenticated peer to keep attacker-controlled aggregate state alive across a security-limit exception and pin retained pooled buffers. This issue is fixed in versions 4.1.136.Final and 4.2.16.Final. |
| In sol commit 373d848 (2024-12-12), the broker does not fully release resources when handling malformed or duplicate CONNECT packets. When clients send invalid CONNECT packets - either due to repeated attempts or failed authentication - the server may silently drop the connection or send a CONNACK but fail to close the session or deallocate internal resources. This behavior allows an attacker to create numerous half-open connections that consume memory and file descriptors indefinitely, potentially triggering the Linux OOM killer and causing a denial of service. |
| A vulnerability in the Simple Network Management Protocol (SNMP) subsystem of Cisco IOS XE Software could allow an authenticated, remote attacker to cause an affected device to reload, resulting in a denial of service (DoS) condition.
This vulnerability is due to improper error handling when parsing SNMP requests. This vulnerability affects all versions of SNMP — Versions 1, 2c, and 3. An attacker could exploit this vulnerability by sending a malformed SNMP request to an affected device. A successful exploit could allow the attacker to cause the device to reload unexpectedly. The attacker must have the SNMPv1 or v2c read-only or read-write community string or valid SNMPv3 user credentials on the affected device. |
| A vulnerability was found in libsoup's HTTP/2 protocol implementation. The library fails to correctly release memory context blocks under specific stream termination conditions, such as when an HTTP/2 connection encounters window exhaustion or explicit stream resets. A remote, unauthenticated attacker acting as a malicious network peer can trick the connection engine into allocating stream states that are subsequently leaked during cleanup. Over a sustained period, this flaw allows the remote attacker to consume the system's heap allocations incrementally, triggering a denial of service (DoS) through an ultimate Out-of-Memory (OOM) application crash. |
| In Eclipse Milo versions 1.0.0 through 1.1.4, monitored-item quota accounting is not exception-safe: if item creation fails with an unchecked error, the server-global reservation is not restored. Deeply nested PubSub ExtensionObjects in a `CreateMonitoredItems` event filter can trigger a `StackOverflowError` during decoding, allowing an unauthenticated remote client to exhaust a finite global monitored-item quota and prevent all clients from creating new monitored items until restart. Existing monitored items and other server functions remain unaffected. |
| In the Linux kernel, the following vulnerability has been resolved:
iio: light: gp2ap002: fix runtime PM leak on read error
gp2ap002_read_raw() calls pm_runtime_get_sync() before reading the
lux value, but if gp2ap002_get_lux() fails, it returns directly. This
skips the pm_runtime_put_autosuspend() call at the "out" label,
permanently leaking a runtime PM reference and preventing the device
from autosuspending.
Replace the direct return with a "goto out" to ensure the reference
is properly dropped on the error path. |
| In the Linux kernel, the following vulnerability has been resolved:
netfilter: nft_socket: fix sk refcount leaks
We must put 'sk' reference before returning. |
| In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_conn: Fix memory leak in hci_le_big_terminate()
hci_le_big_terminate() allocates iso_list_data via kzalloc_obj but
returns 0 without freeing it when neither pa_sync_term nor big_sync_term
flags are set after evaluating the PA and BIG sync connection state.
This early-return path was introduced when hci_le_big_terminate() was
refactored to take struct hci_conn instead of raw u8 parameters, adding
PA/BIG flag evaluation logic. The existing kfree() on hci_cmd_sync_queue
failure does not cover this path. |
| An unauthenticated attacker could trigger an Out of Memory condition to crash the Java process for RHCS by repeatedly sending HTTP requests to the TLS endpoint. Depending on how the RHCS server is configured, a manual intervention to restart it may prove necessary. |
| An issue in EMQ NanoMQ v.0.24.9 allows a remote attacker to cause a denial of service via the nni_qos_db_set function in broker_tcp.c component |
| In the Linux kernel, the following vulnerability has been resolved:
PCI: mediatek: Fix IRQ domain leak when port fails to enable
When mtk_pcie_enable_port() fails, mtk_pcie_port_free() removes the port
from pcie->ports and frees the port structure. However, the IRQ domains set
up earlier by mtk_pcie_init_irq_domain() are never freed.
Fix this by refactoring mtk_pcie_irq_teardown() into a per-port helper,
mtk_pcie_irq_teardown_port(), and calling it from mtk_pcie_setup() when
mtk_pcie_enable_port() fails. Since the IRQ teardown must only happen in
the probe error path (during resume, child devices may have active MSI
mappings and the NOIRQ context prohibits sleeping locks),
mtk_pcie_enable_port() is changed to return an error code so callers can
distinguish the two paths and act accordingly.
This issue was reported by Sashiko while reviewing the EcoNet EN7528 SoC
support series. |
| In the Linux kernel, the following vulnerability has been resolved:
ALSA: compress: Fix task creation error unwind
snd_compr_task_new() allocates the driver task before validating the
returned DMA buffers and reserving file descriptors. When either of
those later steps fails, the core frees its task wrapper and DMA-buffer
references without calling the driver's task_free() callback. Any
driver resources allocated by task_create() are therefore leaked.
The dual-fd allocation path also jumps to cleanup without storing the
negative get_unused_fd_flags() result in retval. Since retval still
contains the successful task_create() return value, TASK_CREATE can
incorrectly report success although the task was discarded.
Preserve the fd allocation errors and call task_free() when failure
occurs after a successful task_create() callback. |
| In the Linux kernel, the following vulnerability has been resolved:
iio: pressure: mpl115: fix runtime PM leak on read error
mpl115_read_raw() takes a runtime PM reference with pm_runtime_get_sync()
before reading the processed pressure or raw temperature, but on the read
error path it returns without calling pm_runtime_put_autosuspend(). Each
failed read therefore leaks a runtime PM reference and prevents the device
from autosuspending.
Drop the reference before checking the return value so both the success
and error paths are balanced. |
| In the Linux kernel, the following vulnerability has been resolved:
iio: adc: ad_sigma_delta: fix CS held asserted and state leaks
In ad_sigma_delta_single_conversion(), set_mode(AD_SD_MODE_IDLE) and
disable_one() were called from the out: block while keep_cs_asserted
was still true. This caused any SPI transfer issued by those callbacks
to carry cs_change=1, leaving CS permanently asserted after the
conversion. Fix by moving both calls into the out_unlock: block, after
keep_cs_asserted is cleared, matching the pattern already used in
ad_sd_calibrate().
In the error path of ad_sd_buffer_postenable(), if an operation fails
after set_mode(AD_SD_MODE_CONTINUOUS) has already succeeded (e.g.
spi_offload_trigger_enable()), the device is left in continuous
conversion mode with CS physically asserted. Additionally,
bus_locked remaining true after spi_bus_unlock() causes subsequent
SPI operations to call spi_sync_locked() without the bus lock actually
held, allowing concurrent SPI access.
Fix the error path by clearing keep_cs_asserted first, then calling
set_mode(AD_SD_MODE_IDLE) to revert the device mode and deassert CS,
then clearing bus_locked before releasing the bus.
For devices that implement neither set_mode nor disable_one (such as
MAX11205, which has no physical CS pin), no SPI transfer is issued
during cleanup and the cs_change flag has no effect on any physical
line. |
| In the Linux kernel, the following vulnerability has been resolved:
ethtool: rss: fix indir_table and hkey leak on get_rxfh failure
rss_prepare_get() allocates the indirection table and hash key buffer
via rss_get_data_alloc(), then calls ops->get_rxfh() to populate them.
If get_rxfh() fails, the function returns an error without freeing
the allocation. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/xe/oa: Fix exec_queue leak on width check in stream open
In xe_oa_stream_open_ioctl(), when param.exec_q->width > 1 the
function returns -EOPNOTSUPP directly, skipping the existing
err_exec_q cleanup path. The exec_queue reference obtained by
xe_exec_queue_lookup() is leaked.
The exec queue holds a reference on the xe_file, which is only
dropped during queue teardown. The leaked lookup ref is not on
the file's exec_queue xarray, so file close cannot release it.
This keeps both the exec queue and the file private state pinned
indefinitely.
Jump to err_exec_q instead of returning directly so the reference
is released.
(cherry picked from commit 339fa0be9e4a5d69fa47e91f4a36574224fb478f) |
| In NLnet Labs Unbound 1.20.0 up to and including 1.25.1, when Unbound is configured with 'serve-expired: yes' and 'serve-expired-client-timeout > discard-timeout > 0' (contrary to the suggested values), the discard-timeout branch during the serve expired logic drops an aged client reply without performing the correct accounting for the number of reply addresses for the query. Other identical branches outside of serve expired perform the correct decrement. Since the counter is never decremented in such scenario, it can reach the maximum limit and new clients for duplicate in-flight queries are silently dropped resulting in degradation of resolution service. A malicious actor can exploit the vulnerability by querying the resolver for a client-controlled slow-on-demand authoritative zone that can drive the counter past the threshold. Shipped defaults for 'serve-expired-client-timeout: 1800' and 'discard-timeout: 1900' make the branch unreachable. |
| In the Linux kernel, the following vulnerability has been resolved:
espintcp: fix skb leaks
A few error paths are missing a kfree_skb. |
