| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
perf trace: Really free the evsel->priv area
In 3cb4d5e00e037c70 ("perf trace: Free syscall tp fields in
evsel->priv") it only was freeing if strcmp(evsel->tp_format->system,
"syscalls") returned zero, while the corresponding initialization of
evsel->priv was being performed if it was _not_ zero, i.e. if the tp
system wasn't 'syscalls'.
Just stop looking for that and free it if evsel->priv was set, which
should be equivalent.
Also use the pre-existing evsel_trace__delete() function.
This resolves these leaks, detected with:
$ make EXTRA_CFLAGS="-fsanitize=address" BUILD_BPF_SKEL=1 CORESIGHT=1 O=/tmp/build/perf-tools-next -C tools/perf install-bin
=================================================================
==481565==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 40 byte(s) in 1 object(s) allocated from:
#0 0x7f7343cba097 in calloc (/lib64/libasan.so.8+0xba097)
#1 0x987966 in zalloc (/home/acme/bin/perf+0x987966)
#2 0x52f9b9 in evsel_trace__new /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:307
#3 0x52f9b9 in evsel__syscall_tp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:333
#4 0x52f9b9 in evsel__init_raw_syscall_tp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:458
#5 0x52f9b9 in perf_evsel__raw_syscall_newtp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:480
#6 0x540e8b in trace__add_syscall_newtp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:3212
#7 0x540e8b in trace__run /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:3891
#8 0x540e8b in cmd_trace /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:5156
#9 0x5ef262 in run_builtin /home/acme/git/perf-tools-next/tools/perf/perf.c:323
#10 0x4196da in handle_internal_command /home/acme/git/perf-tools-next/tools/perf/perf.c:377
#11 0x4196da in run_argv /home/acme/git/perf-tools-next/tools/perf/perf.c:421
#12 0x4196da in main /home/acme/git/perf-tools-next/tools/perf/perf.c:537
#13 0x7f7342c4a50f in __libc_start_call_main (/lib64/libc.so.6+0x2750f)
Direct leak of 40 byte(s) in 1 object(s) allocated from:
#0 0x7f7343cba097 in calloc (/lib64/libasan.so.8+0xba097)
#1 0x987966 in zalloc (/home/acme/bin/perf+0x987966)
#2 0x52f9b9 in evsel_trace__new /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:307
#3 0x52f9b9 in evsel__syscall_tp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:333
#4 0x52f9b9 in evsel__init_raw_syscall_tp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:458
#5 0x52f9b9 in perf_evsel__raw_syscall_newtp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:480
#6 0x540dd1 in trace__add_syscall_newtp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:3205
#7 0x540dd1 in trace__run /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:3891
#8 0x540dd1 in cmd_trace /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:5156
#9 0x5ef262 in run_builtin /home/acme/git/perf-tools-next/tools/perf/perf.c:323
#10 0x4196da in handle_internal_command /home/acme/git/perf-tools-next/tools/perf/perf.c:377
#11 0x4196da in run_argv /home/acme/git/perf-tools-next/tools/perf/perf.c:421
#12 0x4196da in main /home/acme/git/perf-tools-next/tools/perf/perf.c:537
#13 0x7f7342c4a50f in __libc_start_call_main (/lib64/libc.so.6+0x2750f)
SUMMARY: AddressSanitizer: 80 byte(s) leaked in 2 allocation(s).
[root@quaco ~]#
With this we plug all leaks with "perf trace sleep 1". |
| In the Linux kernel, the following vulnerability has been resolved:
fbdev: omapfb: lcd_mipid: Fix an error handling path in mipid_spi_probe()
If 'mipid_detect()' fails, we must free 'md' to avoid a memory leak. |
| In the Linux kernel, the following vulnerability has been resolved:
accel/qaic: Fix a leak in map_user_pages()
If get_user_pages_fast() allocates some pages but not as many as we
wanted, then the current code leaks those pages. Call put_page() on
the pages before returning. |
| In tinyMQTT commit 6226ade15bd4f97be2d196352e64dd10937c1962 (2024-02-18), a memory leak occurs due to the broker's failure to validate or reject malformed UTF-8 strings in topic filters. An attacker can exploit this by sending repeated subscription requests with arbitrarily large or invalid filter payloads. Each request causes memory to be allocated for the malformed topic filter, but the broker does not free the associated memory, leading to unbounded heap growth and potential denial of service under sustained attack. |
| A Missing Release of Memory after Effective Lifetime vulnerability in the routing protocol daemon (rpd) of Juniper Networks Junos OS and Junos OS Evolved allows a local, low privileged user to cause an impact to the availability of the device.
When RIB sharding is enabled and a user executes one of several routing related 'show' commands, a certain amount of memory is leaked. When all available memory has been consumed rpd will crash and restart.
The leak can be monitored with the CLI command:
show task memory detail | match task_shard_mgmt_cookie
where the allocated memory in bytes can be seen to continuously increase with each exploitation.
This issue affects:
Junos OS:
* all versions before 21.2R3-S9,
* 21.4 versions before 21.4R3-S11,
* 22.2 versions before 22.2R3-S7,
* 22.4 versions before 22.4R3-S7,
* 23.2 versions before 23.2R2-S4,
* 23.4 versions before 23.4R2-S4,
* 24.2 versions before 24.2R2,
* 24.4 versions before 24.4R1-S2, 24.4R2;
Junos OS Evolved:
* all versions before 22.2R3-S7-EVO
* 22.4-EVO versions before 22.4R3-S7-EVO,
* 23.2-EVO versions before 23.2R2-S4-EVO,
* 23.4-EVO versions before 23.4R2-S4-EVO,
* 24.2-EVO versions before 24.2R2-EVO,
* 24.4-EVO versions before 24.4R2-EVO. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: csa unmap use uninterruptible lock
After process exit to unmap csa and free GPU vm, if signal is accepted
and then waiting to take vm lock is interrupted and return, it causes
memory leaking and below warning backtrace.
Change to use uninterruptible wait lock fix the issue.
WARNING: CPU: 69 PID: 167800 at amd/amdgpu/amdgpu_kms.c:1525
amdgpu_driver_postclose_kms+0x294/0x2a0 [amdgpu]
Call Trace:
<TASK>
drm_file_free.part.0+0x1da/0x230 [drm]
drm_close_helper.isra.0+0x65/0x70 [drm]
drm_release+0x6a/0x120 [drm]
amdgpu_drm_release+0x51/0x60 [amdgpu]
__fput+0x9f/0x280
____fput+0xe/0x20
task_work_run+0x67/0xa0
do_exit+0x217/0x3c0
do_group_exit+0x3b/0xb0
get_signal+0x14a/0x8d0
arch_do_signal_or_restart+0xde/0x100
exit_to_user_mode_loop+0xc1/0x1a0
exit_to_user_mode_prepare+0xf4/0x100
syscall_exit_to_user_mode+0x17/0x40
do_syscall_64+0x69/0xc0
(cherry picked from commit 7dbbfb3c171a6f63b01165958629c9c26abf38ab) |
| 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 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:
mm/kmemleak: avoid soft lockup in __kmemleak_do_cleanup()
A soft lockup warning was observed on a relative small system x86-64
system with 16 GB of memory when running a debug kernel with kmemleak
enabled.
watchdog: BUG: soft lockup - CPU#8 stuck for 33s! [kworker/8:1:134]
The test system was running a workload with hot unplug happening in
parallel. Then kemleak decided to disable itself due to its inability to
allocate more kmemleak objects. The debug kernel has its
CONFIG_DEBUG_KMEMLEAK_MEM_POOL_SIZE set to 40,000.
The soft lockup happened in kmemleak_do_cleanup() when the existing
kmemleak objects were being removed and deleted one-by-one in a loop via a
workqueue. In this particular case, there are at least 40,000 objects
that need to be processed and given the slowness of a debug kernel and the
fact that a raw_spinlock has to be acquired and released in
__delete_object(), it could take a while to properly handle all these
objects.
As kmemleak has been disabled in this case, the object removal and
deletion process can be further optimized as locking isn't really needed.
However, it is probably not worth the effort to optimize for such an edge
case that should rarely happen. So the simple solution is to call
cond_resched() at periodic interval in the iteration loop to avoid soft
lockup. |
| 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/ab580a75-91c8-d68a-3455-40361be1bfa8@linux.alibaba.com/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. |
| 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. |
| 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. |
| In the Linux kernel, the following vulnerability has been resolved:
PM / devfreq: Fix leak in devfreq_dev_release()
srcu_init_notifier_head() allocates resources that need to be released
with a srcu_cleanup_notifier_head() call.
Reported by kmemleak. |
