| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer). Supported versions that are affected are 9.0.0-9.5.0. Easily exploitable vulnerability allows low 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 6.5 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). |
| Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Parser). Supported versions that are affected are 9.0.0-9.5.0. 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). |
| Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer). Supported versions that are affected are 9.0.0-9.5.0. Easily exploitable vulnerability allows low 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 6.5 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). |
| Vulnerability in the Java VM component of Oracle Database Server. Supported versions that are affected are 19.3-19.29 and 21.3-21.20. Easily exploitable vulnerability allows high privileged attacker having Authenticated User privilege with network access via Oracle Net to compromise Java VM. Successful attacks require human interaction from a person other than the attacker. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of Java VM. CVSS 3.1 Base Score 4.5 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:R/S:U/C:N/I:N/A:H). |
| FFmpeg git-master before commit d5873b was discovered to contain a memory leak in the component libavutil/iamf.c. |
| Missing Release of Memory after Effective Lifetime vulnerability in Is-Daouda is-Engine.This issue affects is-Engine: before 3.3.4. |
| Missing Release of Memory after Effective Lifetime vulnerability in ydb-platform ydb (contrib/libs/yajl modules). This vulnerability is associated with program files yail_tree.C.
This issue affects ydb: through 24.4.4.2. |
| In the Linux kernel, the following vulnerability has been resolved:
ice: fix Rx page leak on multi-buffer frames
The ice_put_rx_mbuf() function handles calling ice_put_rx_buf() for each
buffer in the current frame. This function was introduced as part of
handling multi-buffer XDP support in the ice driver.
It works by iterating over the buffers from first_desc up to 1 plus the
total number of fragments in the frame, cached from before the XDP program
was executed.
If the hardware posts a descriptor with a size of 0, the logic used in
ice_put_rx_mbuf() breaks. Such descriptors get skipped and don't get added
as fragments in ice_add_xdp_frag. Since the buffer isn't counted as a
fragment, we do not iterate over it in ice_put_rx_mbuf(), and thus we don't
call ice_put_rx_buf().
Because we don't call ice_put_rx_buf(), we don't attempt to re-use the
page or free it. This leaves a stale page in the ring, as we don't
increment next_to_alloc.
The ice_reuse_rx_page() assumes that the next_to_alloc has been incremented
properly, and that it always points to a buffer with a NULL page. Since
this function doesn't check, it will happily recycle a page over the top
of the next_to_alloc buffer, losing track of the old page.
Note that this leak only occurs for multi-buffer frames. The
ice_put_rx_mbuf() function always handles at least one buffer, so a
single-buffer frame will always get handled correctly. It is not clear
precisely why the hardware hands us descriptors with a size of 0 sometimes,
but it happens somewhat regularly with "jumbo frames" used by 9K MTU.
To fix ice_put_rx_mbuf(), we need to make sure to call ice_put_rx_buf() on
all buffers between first_desc and next_to_clean. Borrow the logic of a
similar function in i40e used for this same purpose. Use the same logic
also in ice_get_pgcnts().
Instead of iterating over just the number of fragments, use a loop which
iterates until the current index reaches to the next_to_clean element just
past the current frame. Unlike i40e, the ice_put_rx_mbuf() function does
call ice_put_rx_buf() on the last buffer of the frame indicating the end of
packet.
For non-linear (multi-buffer) frames, we need to take care when adjusting
the pagecnt_bias. An XDP program might release fragments from the tail of
the frame, in which case that fragment page is already released. Only
update the pagecnt_bias for the first descriptor and fragments still
remaining post-XDP program. Take care to only access the shared info for
fragmented buffers, as this avoids a significant cache miss.
The xdp_xmit value only needs to be updated if an XDP program is run, and
only once per packet. Drop the xdp_xmit pointer argument from
ice_put_rx_mbuf(). Instead, set xdp_xmit in the ice_clean_rx_irq() function
directly. This avoids needing to pass the argument and avoids an extra
bit-wise OR for each buffer in the frame.
Move the increment of the ntc local variable to ensure its updated *before*
all calls to ice_get_pgcnts() or ice_put_rx_mbuf(), as the loop logic
requires the index of the element just after the current frame.
Now that we use an index pointer in the ring to identify the packet, we no
longer need to track or cache the number of fragments in the rx_ring. |
| In Eclipse Jetty, versions <=9.4.57, <=10.0.25, <=11.0.25, <=12.0.21, <=12.1.0.alpha2, an HTTP/2 client may trigger the server to send RST_STREAM frames, for example by sending frames that are malformed or that should not be sent in a particular stream state, therefore forcing the server to consume resources such as CPU and memory.
For example, a client can open a stream and then send WINDOW_UPDATE frames with window size increment of 0, which is illegal.
Per specification https://www.rfc-editor.org/rfc/rfc9113.html#name-window_update , the server should send a RST_STREAM frame.
The client can now open another stream and send another bad WINDOW_UPDATE, therefore causing the server to consume more resources than necessary, as this case does not exceed the max number of concurrent streams, yet the client is able to create an enormous amount of streams in a short period of time.
The attack can be performed with other conditions (for example, a DATA frame for a closed stream) that cause the server to send a RST_STREAM frame.
Links:
* https://github.com/jetty/jetty.project/security/advisories/GHSA-mmxm-8w33-wc4h |
| In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix smbdirect_recv_io leak in smbd_negotiate() error path
During tests of another unrelated patch I was able to trigger this
error: Objects remaining on __kmem_cache_shutdown() |
| In the Linux kernel, the following vulnerability has been resolved:
io_uring: fix fget leak when fs don't support nowait buffered read
Heming reported a BUG when using io_uring doing link-cp on ocfs2. [1]
Do the following steps can reproduce this BUG:
mount -t ocfs2 /dev/vdc /mnt/ocfs2
cp testfile /mnt/ocfs2/
./link-cp /mnt/ocfs2/testfile /mnt/ocfs2/testfile.1
umount /mnt/ocfs2
Then umount will fail, and it outputs:
umount: /mnt/ocfs2: target is busy.
While tracing umount, it blames mnt_get_count() not return as expected.
Do a deep investigation for fget()/fput() on related code flow, I've
finally found that fget() leaks since ocfs2 doesn't support nowait
buffered read.
io_issue_sqe
|-io_assign_file // do fget() first
|-io_read
|-io_iter_do_read
|-ocfs2_file_read_iter // return -EOPNOTSUPP
|-kiocb_done
|-io_rw_done
|-__io_complete_rw_common // set REQ_F_REISSUE
|-io_resubmit_prep
|-io_req_prep_async // override req->file, leak happens
This was introduced by commit a196c78b5443 in v5.18. Fix it by don't
re-assign req->file if it has already been assigned.
[1] https://lore.kernel.org/ocfs2-devel/[email protected]/T/#t |
| A Missing Release of Memory after Effective Lifetime vulnerability in the Packet Forwarding Engine (PFE) of Juniper Networks Junos OS and Junos OS Evolved allows an adjacent, unauthenticated attacker to cause an FPC to crash, leading to Denial of Service (DoS).
On all Junos OS and Junos OS Evolved platforms, in an EVPN-VXLAN scenario, when specific ARP packets are received on an IPv4 network, or specific NDP packets are received on an IPv6 network, kernel heap memory leaks, which eventually leads to an FPC crash and restart.
This issue does not affect MX Series platforms.
Heap size growth on FPC can be seen using below command.
user@host> show chassis fpc
Temp CPU Utilization (%) CPU Utilization (%) Memory Utilization (%)
Slot State (C) Total Interrupt 1min 5min 15min DRAM (MB) Heap Buffer
0 Online 45 3 0 2 2 2 32768 19 0 <<<<<<< Heap increase in all fPCs
This issue affects Junos OS:
* All versions before 21.2R3-S7,
* 21.4 versions before 21.4R3-S4,
* 22.2 versions before 22.2R3-S1,
* 22.3 versions before 22.3R3-S1,
* 22.4 versions before 22.4R2-S2, 22.4R3.
and Junos OS Evolved:
* All versions before 21.2R3-S7-EVO,
* 21.4-EVO versions before 21.4R3-S4-EVO,
* 22.2-EVO versions before 22.2R3-S1-EVO,
* 22.3-EVO versions before 22.3R3-S1-EVO,
* 22.4-EVO versions before 22.4R3-EVO. |
| A Missing Release of Memory after Effective Lifetime vulnerability in the Juniper Tunnel Driver (jtd) of Juniper Networks Junos OS Evolved allows an unauthenticated network-based attacker to cause Denial of Service.
Receipt of specifically malformed IPv6 packets, destined to the device, causes kernel memory to not be freed, resulting in memory exhaustion leading to a system crash and Denial of Service (DoS). Continuous receipt and processing of these packets will continue to exhaust kernel memory, creating a sustained Denial of Service (DoS) condition.
This issue only affects systems configured with IPv6.
This issue affects Junos OS Evolved:
* from 22.4-EVO before 22.4R3-S5-EVO,
* from 23.2-EVO before 23.2R2-S2-EVO,
* from 23.4-EVO before 23.4R2-S2-EVO,
* from 24.2-EVO before 24.2R1-S2-EVO, 24.2R2-EVO.
This issue does not affect Juniper Networks Junos OS Evolved versions prior to 22.4R1-EVO. |
| A Missing Release of Memory after Effective Lifetime vulnerability in the packet forwarding engine (PFE) of Juniper Networks Junos OS on MX Series allows an unauthenticated adjacent attacker to cause a Denial-of-Service (DoS).
In a subscriber management scenario, login/logout activity triggers a memory leak, and the leaked memory gradually increments and eventually results in a crash.
user@host> show chassis fpc
Temp CPU Utilization (%) CPU Utilization (%) Memory Utilization (%)
Slot State (C) Total Interrupt 1min 5min 15min DRAM (MB) Heap Buffer
2 Online 36 10 0 9 8 9 32768 26 0
This issue affects Junos OS on MX Series:
* All versions before 21.2R3-S9
* from 21.4 before 21.4R3-S10
* from 22.2 before 22.2R3-S6
* from 22.4 before 22.4R3-S5
* from 23.2 before 23.2R2-S3
* from 23.4 before 23.4R2-S3
* from 24.2 before 24.2R2. |
| A Missing Release of Memory after Effective Lifetime vulnerability in the Packet Forwarding Engine (PFE) of the Juniper Networks Junos OS on the MX Series platforms with Trio-based FPCs allows an unauthenticated, adjacent attacker to cause a Denial of Service (DoS).
In case of channelized Modular Interface Cards (MICs), every physical interface flap operation will leak heap memory. Over a period of time, continuous physical interface flap operations causes local FPC to eventually run out of memory and crash.
Below CLI command can be used to check the memory usage over a period of time:
user@host> show chassis fpc
Temp CPU Utilization (%) CPU Utilization (%) Memory
Utilization (%)
Slot State (C) Total Interrupt 1min 5min
15min DRAM (MB) Heap Buffer
0
Online 43 41
2 2048 49 14
1
Online 43 41
2
2048 49 14
2
Online 43 41
2
2048 49 14
This issue affects Junos OS on MX Series:
* All versions before 21.2R3-S7,
* from 21.4 before 21.4R3-S6,
* from 22.1 before 22.1R3-S5,
* from 22.2 before 22.2R3-S3,
* from 22.3 before 22.3R3-S2,
* from 22.4 before 22.4R3,
* from 23.2 before 23.2R2,
* from 23.4 before 23.4R2. |
| An Uncontrolled Resource Consumption vulnerability in the http daemon (httpd) of Juniper Networks Junos OS on SRX Series, QFX Series, MX Series and EX Series allows an unauthenticated, network-based attacker to cause Denial-of-Service (DoS).
An attacker can send specific HTTPS connection requests to the device, triggering the creation of processes that are not properly terminated. Over time, this leads to resource exhaustion, ultimately causing the device to crash and restart.
The following command can be used to monitor the resource usage:
user@host> show system processes extensive | match mgd | count
This issue affects Junos OS on SRX Series and EX Series:
All versions before 21.4R3-S7,
from 22.2 before 22.2R3-S4,
from 22.3 before 22.3R3-S3,
from 22.4 before 22.4R3-S2,
from 23.2 before 23.2R2-S1,
from 23.4 before 23.4R1-S2, 23.4R2. |
| Multiple denial-of-service vulnerabilities exist in the affected product. These issues can be triggered through various crafted inputs, including malformed Class 3 messages, memory leak conditions, and other resource exhaustion scenarios. Exploitation may cause the device to become unresponsive and, in some cases, result in a major nonrecoverable fault. Recovery may require a restart. |
| A vulnerability in the SSH service of Cisco IEC6400 Wireless Backhaul Edge Compute Software could allow an unauthenticated, remote attacker to cause the SSH service to stop responding.
This vulnerability exists because the SSH service lacks effective flood protection. An attacker could exploit this vulnerability by initiating a denial of service (DoS) attack against the SSH port. A successful exploit could allow the attacker to cause the SSH service to be unresponsive during the period of the DoS attack. All other operations remain stable during the attack. |
| In jose4j before 0.9.6, an attacker can cause a Denial-of-Service (DoS) condition by crafting a malicious JSON Web Encryption (JWE) token with an exceptionally high compression ratio. When this token is processed by the server, it results in significant memory allocation and processing time during decompression. |
| In the Linux kernel, the following vulnerability has been resolved:
thunderbolt: Fix memory leak in tb_handle_dp_bandwidth_request()
The memory allocated in tb_queue_dp_bandwidth_request() needs to be
released once the request is handled to avoid leaking it. |
