Missing Release of Memory after Effective LifetimeCWE-401
| CVE ID | CVSS | Vendor | Exploit | Patch | Trends |
|---|---|---|---|---|---|
CVE-2024-8376In Eclipse Mosquitto up to version 2.0.18a, an attacker can achieve memory leaking, segmentation fault or heap-use-after-free by sending specific sequences of "CONNECT", "DISCONNECT", "SUBSCRIBE", "UNSUBSCRIBE" and "PUBLISH" packets. | CVSS 7.5 | Eclipse | - | Patched |  |
CVE-2024-7884When a canister method is called via ic_cdk::call* , a new Future CallFuture is created and can be awaited by the caller to get the execution result. Internally, the state of the Future is tracked and stored in a struct called CallFutureState. A bug in the polling implementation of the CallFuture allows multiple references to be held for this internal state and not all references were dropped before the Future is resolved. Since we have unaccounted references held, a copy of the internal state ended up being persisted in the canister's heap and thus causing a memory leak.
Impact Canisters built in Rust with ic_cdk and ic_cdk_timers are affected. If these canisters call a canister method, use timers or heartbeat, they will likely leak a small amount of memory on every such operation. In the worst case, this could lead to heap memory exhaustion triggered by an attacker. Motoko based canisters are not affected by the bug.
PatchesThe patch has been backported to all minor versions between >= 0.8.0, <= 0.15.0. The patched versions available are 0.8.2, 0.9.3, 0.10.1, 0.11.6, 0.12.2, 0.13.5, 0.14.1, 0.15.1 and their previous versions have been yanked. WorkaroundsThere are no known workarounds at the moment. Developers are recommended to upgrade their canister as soon as possible to the latest available patched version of ic_cdk to avoid running out of Wasm heap memory.
Upgrading the canisters (without updating `ic_cdk`) also frees the leaked memory but it's only a temporary solution. | CVSS 7.5 | Webassembly, et al | - | Patched |  |
CVE-2024-5294This vulnerability allows network-adjacent attackers to create a denial-of-service condition on affected installations of D-Link DIR-3040 routers. Authentication is not required to exploit this vulnerability.<br/>The specific flaw exists within the prog.cgi program, which handles HNAP requests made to the lighttpd webserver listening on ports 80 and 443. The issue results from the lack of proper memory management when processing HTTP cookie values. An attacker can leverage this vulnerability to create a denial-of-service condition on the system.<br/> <p>08/16/23 – ZDI reported the vulnerabilities to the vendor<br/>08/24/23 – The vendor communicated that the cases would be fixed in Q4, 2023 release<br/>05/01/24 – ZDI notified the vendor of the intention to publish the case as 0-day advisory on 05/14/24</p><p>-- Mitigation: On May 14, 2024, the vendor informed ZDI about the beta software update v120B03a Beta Hot-Fix <a href="https://supportannouncement.us.dlink.com/security/publication.aspx?name=SAP10387" rel="nofollow">https://supportannouncement.us.dlink.com/security/publication.aspx?name=SAP10387</a></p><br/></td> | CVSS Low | Dlink | Exploit | - |  |
CVE-2024-50254In the Linux kernel, the following vulnerability has been resolved:
bpf: Free dynamically allocated bits in bpf_iter_bits_destroy()
bpf_iter_bits_destroy() uses "kit->nr_bits <= 64" to check whether the
bits are dynamically allocated. However, the check is incorrect and may
cause a kmemleak as shown below:
unreferenced object 0xffff88812628c8c0 (size 32):
comm "swapper/0", pid 1, jiffies 4294727320
hex dump (first 32 bytes):
b0 c1 55 f5 81 88 ff ff f0 f0 f0 f0 f0 f0 f0 f0 ..U...........
f0 f0 f0 f0 f0 f0 f0 f0 00 00 00 00 00 00 00 00 ..............
backtrace (crc 781e32cc):
[<00000000c452b4ab>] kmemleak_alloc+0x4b/0x80
[<0000000004e09f80>] __kmalloc_node_noprof+0x480/0x5c0
[<00000000597124d6>] __alloc.isra.0+0x89/0xb0
[<000000004ebfffcd>] alloc_bulk+0x2af/0x720
[<00000000d9c10145>] prefill_mem_cache+0x7f/0xb0
[<00000000ff9738ff>] bpf_mem_alloc_init+0x3e2/0x610
[<000000008b616eac>] bpf_global_ma_init+0x19/0x30
[<00000000fc473efc>] do_one_initcall+0xd3/0x3c0
[<00000000ec81498c>] kernel_init_freeable+0x66a/0x940
[<00000000b119f72f>] kernel_init+0x20/0x160
[<00000000f11ac9a7>] ret_from_fork+0x3c/0x70
[<0000000004671da4>] ret_from_fork_asm+0x1a/0x30
That is because nr_bits will be set as zero in bpf_iter_bits_next()
after all bits have been iterated.
Fix the issue by setting kit->bit to kit->nr_bits instead of setting
kit->nr_bits to zero when the iteration completes in
bpf_iter_bits_next(). In addition, use "!nr_bits || bits >= nr_bits" to
check whether the iteration is complete and still use "nr_bits > 64" to
indicate whether bits are dynamically allocated. The "!nr_bits" check is
necessary because bpf_iter_bits_new() may fail before setting
kit->nr_bits, and this condition will stop the iteration early instead
of accessing the zeroed or freed kit->bits.
Considering the initial value of kit->bits is -1 and the type of
kit->nr_bits is unsigned int, change the type of kit->nr_bits to int.
The potential overflow problem will be handled in the following patch. | CVSS 5.5 | Linux | - | Patched |  |
CVE-2024-50252In the Linux kernel, the following vulnerability has been resolved:
mlxsw: spectrum_ipip: Fix memory leak when changing remote IPv6 address
The device stores IPv6 addresses that are used for encapsulation in
linear memory that is managed by the driver.
Changing the remote address of an ip6gre net device never worked
properly, but since cited commit the following reproducer [1] would
result in a warning [2] and a memory leak [3]. The problem is that the
new remote address is never added by the driver to its hash table (and
therefore the device) and the old address is never removed from it.
Fix by programming the new address when the configuration of the ip6gre
net device changes and removing the old one. If the address did not
change, then the above would result in increasing the reference count of
the address and then decreasing it.
[1]
# ip link add name bla up type ip6gre local 2001:db8:1::1 remote 2001:db8:2::1 tos inherit ttl inherit
# ip link set dev bla type ip6gre remote 2001:db8:3::1
# ip link del dev bla
# devlink dev reload pci/0000:01:00.0
[2]
WARNING: CPU: 0 PID: 1682 at drivers/net/ethernet/mellanox/mlxsw/spectrum.c:3002 mlxsw_sp_ipv6_addr_put+0x140/0x1d0
Modules linked in:
CPU: 0 UID: 0 PID: 1682 Comm: ip Not tainted 6.12.0-rc3-custom-g86b5b55bc835 #151
Hardware name: Nvidia SN5600/VMOD0013, BIOS 5.13 05/31/2023
RIP: 0010:mlxsw_sp_ipv6_addr_put+0x140/0x1d0
[...]
Call Trace:
<TASK>
mlxsw_sp_router_netdevice_event+0x55f/0x1240
notifier_call_chain+0x5a/0xd0
call_netdevice_notifiers_info+0x39/0x90
unregister_netdevice_many_notify+0x63e/0x9d0
rtnl_dellink+0x16b/0x3a0
rtnetlink_rcv_msg+0x142/0x3f0
netlink_rcv_skb+0x50/0x100
netlink_unicast+0x242/0x390
netlink_sendmsg+0x1de/0x420
____sys_sendmsg+0x2bd/0x320
___sys_sendmsg+0x9a/0xe0
__sys_sendmsg+0x7a/0xd0
do_syscall_64+0x9e/0x1a0
entry_SYSCALL_64_after_hwframe+0x77/0x7f
[3]
unreferenced object 0xffff898081f597a0 (size 32):
comm "ip", pid 1626, jiffies 4294719324
hex dump (first 32 bytes):
20 01 0d b8 00 02 00 00 00 00 00 00 00 00 00 01 ...............
21 49 61 83 80 89 ff ff 00 00 00 00 01 00 00 00 !Ia.............
backtrace (crc fd9be911):
[<00000000df89c55d>] __kmalloc_cache_noprof+0x1da/0x260
[<00000000ff2a1ddb>] mlxsw_sp_ipv6_addr_kvdl_index_get+0x281/0x340
[<000000009ddd445d>] mlxsw_sp_router_netdevice_event+0x47b/0x1240
[<00000000743e7757>] notifier_call_chain+0x5a/0xd0
[<000000007c7b9e13>] call_netdevice_notifiers_info+0x39/0x90
[<000000002509645d>] register_netdevice+0x5f7/0x7a0
[<00000000c2e7d2a9>] ip6gre_newlink_common.isra.0+0x65/0x130
[<0000000087cd6d8d>] ip6gre_newlink+0x72/0x120
[<000000004df7c7cc>] rtnl_newlink+0x471/0xa20
[<0000000057ed632a>] rtnetlink_rcv_msg+0x142/0x3f0
[<0000000032e0d5b5>] netlink_rcv_skb+0x50/0x100
[<00000000908bca63>] netlink_unicast+0x242/0x390
[<00000000cdbe1c87>] netlink_sendmsg+0x1de/0x420
[<0000000011db153e>] ____sys_sendmsg+0x2bd/0x320
[<000000003b6d53eb>] ___sys_sendmsg+0x9a/0xe0
[<00000000cae27c62>] __sys_sendmsg+0x7a/0xd0 | CVSS 5.5 | Linux | - | Patched |  |
CVE-2024-50237In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: do not pass a stopped vif to the driver in .get_txpower
Avoid potentially crashing in the driver because of uninitialized private data | CVSS 5.5 | Linux | - | Patched |  |
CVE-2024-50236In the Linux kernel, the following vulnerability has been resolved:
wifi: ath10k: Fix memory leak in management tx
In the current logic, memory is allocated for storing the MSDU context
during management packet TX but this memory is not being freed during
management TX completion. Similar leaks are seen in the management TX
cleanup logic.
Kmemleak reports this problem as below,
unreferenced object 0xffffff80b64ed250 (size 16):
comm "kworker/u16:7", pid 148, jiffies 4294687130 (age 714.199s)
hex dump (first 16 bytes):
00 2b d8 d8 80 ff ff ff c4 74 e9 fd 07 00 00 00 .+.......t......
backtrace:
[<ffffffe6e7b245dc>] __kmem_cache_alloc_node+0x1e4/0x2d8
[<ffffffe6e7adde88>] kmalloc_trace+0x48/0x110
[<ffffffe6bbd765fc>] ath10k_wmi_tlv_op_gen_mgmt_tx_send+0xd4/0x1d8 [ath10k_core]
[<ffffffe6bbd3eed4>] ath10k_mgmt_over_wmi_tx_work+0x134/0x298 [ath10k_core]
[<ffffffe6e78d5974>] process_scheduled_works+0x1ac/0x400
[<ffffffe6e78d60b8>] worker_thread+0x208/0x328
[<ffffffe6e78dc890>] kthread+0x100/0x1c0
[<ffffffe6e78166c0>] ret_from_fork+0x10/0x20
Free the memory during completion and cleanup to fix the leak.
Protect the mgmt_pending_tx idr_remove() operation in
ath10k_wmi_tlv_op_cleanup_mgmt_tx_send() using ar->data_lock similar to
other instances.
Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.2.0-01387-QCAHLSWMTPLZ-1 | CVSS 5.5 | Linux | - | Patched |  |
CVE-2024-50231In the Linux kernel, the following vulnerability has been resolved:
iio: gts-helper: Fix memory leaks in iio_gts_build_avail_scale_table()
modprobe iio-test-gts and rmmod it, then the following memory leak
occurs:
unreferenced object 0xffffff80c810be00 (size 64):
comm "kunit_try_catch", pid 1654, jiffies 4294913981
hex dump (first 32 bytes):
02 00 00 00 08 00 00 00 20 00 00 00 40 00 00 00 ........ ...@...
80 00 00 00 00 02 00 00 00 04 00 00 00 08 00 00 ................
backtrace (crc a63d875e):
[<0000000028c1b3c2>] kmemleak_alloc+0x34/0x40
[<000000001d6ecc87>] __kmalloc_noprof+0x2bc/0x3c0
[<00000000393795c1>] devm_iio_init_iio_gts+0x4b4/0x16f4
[<0000000071bb4b09>] 0xffffffdf052a62e0
[<000000000315bc18>] 0xffffffdf052a6488
[<00000000f9dc55b5>] kunit_try_run_case+0x13c/0x3ac
[<00000000175a3fd4>] kunit_generic_run_threadfn_adapter+0x80/0xec
[<00000000f505065d>] kthread+0x2e8/0x374
[<00000000bbfb0e5d>] ret_from_fork+0x10/0x20
unreferenced object 0xffffff80cbfe9e70 (size 16):
comm "kunit_try_catch", pid 1658, jiffies 4294914015
hex dump (first 16 bytes):
10 00 00 00 40 00 00 00 80 00 00 00 00 00 00 00 ....@...........
backtrace (crc 857f0cb4):
[<0000000028c1b3c2>] kmemleak_alloc+0x34/0x40
[<000000001d6ecc87>] __kmalloc_noprof+0x2bc/0x3c0
[<00000000393795c1>] devm_iio_init_iio_gts+0x4b4/0x16f4
[<0000000071bb4b09>] 0xffffffdf052a62e0
[<000000007d089d45>] 0xffffffdf052a6864
[<00000000f9dc55b5>] kunit_try_run_case+0x13c/0x3ac
[<00000000175a3fd4>] kunit_generic_run_threadfn_adapter+0x80/0xec
[<00000000f505065d>] kthread+0x2e8/0x374
[<00000000bbfb0e5d>] ret_from_fork+0x10/0x20
......
It includes 5*5 times "size 64" memory leaks, which correspond to 5 times
test_init_iio_gain_scale() calls with gts_test_gains size 10 (10*size(int))
and gts_test_itimes size 5. It also includes 5*1 times "size 16"
memory leak, which correspond to one time __test_init_iio_gain_scale()
call with gts_test_gains_gain_low size 3 (3*size(int)) and gts_test_itimes
size 5.
The reason is that the per_time_gains[i] is not freed which is allocated in
the "gts->num_itime" for loop in iio_gts_build_avail_scale_table(). | CVSS 5.5 | Linux | - | Patched |  |
CVE-2024-50214In the Linux kernel, the following vulnerability has been resolved:
drm/connector: hdmi: Fix memory leak in drm_display_mode_from_cea_vic()
modprobe drm_connector_test and then rmmod drm_connector_test,
the following memory leak occurs.
The `mode` allocated in drm_mode_duplicate() called by
drm_display_mode_from_cea_vic() is not freed, which cause the memory leak:
unreferenced object 0xffffff80cb0ee400 (size 128):
comm "kunit_try_catch", pid 1948, jiffies 4294950339
hex dump (first 32 bytes):
14 44 02 00 80 07 d8 07 04 08 98 08 00 00 38 04 .D............8.
3c 04 41 04 65 04 00 00 05 00 00 00 00 00 00 00 <.A.e...........
backtrace (crc 90e9585c):
[<00000000ec42e3d7>] kmemleak_alloc+0x34/0x40
[<00000000d0ef055a>] __kmalloc_cache_noprof+0x26c/0x2f4
[<00000000c2062161>] drm_mode_duplicate+0x44/0x19c
[<00000000f96c74aa>] drm_display_mode_from_cea_vic+0x88/0x98
[<00000000d8f2c8b4>] 0xffffffdc982a4868
[<000000005d164dbc>] kunit_try_run_case+0x13c/0x3ac
[<000000006fb23398>] kunit_generic_run_threadfn_adapter+0x80/0xec
[<000000006ea56ca0>] kthread+0x2e8/0x374
[<000000000676063f>] ret_from_fork+0x10/0x20
......
Free `mode` by using drm_kunit_display_mode_from_cea_vic()
to fix it. | CVSS 5.5 | Linux | - | Patched |  |
CVE-2024-50213In the Linux kernel, the following vulnerability has been resolved:
drm/tests: hdmi: Fix memory leaks in drm_display_mode_from_cea_vic()
modprobe drm_hdmi_state_helper_test and then rmmod it, the following
memory leak occurs.
The `mode` allocated in drm_mode_duplicate() called by
drm_display_mode_from_cea_vic() is not freed, which cause the memory leak:
unreferenced object 0xffffff80ccd18100 (size 128):
comm "kunit_try_catch", pid 1851, jiffies 4295059695
hex dump (first 32 bytes):
57 62 00 00 80 02 90 02 f0 02 20 03 00 00 e0 01 Wb........ .....
ea 01 ec 01 0d 02 00 00 0a 00 00 00 00 00 00 00 ................
backtrace (crc c2f1aa95):
[<000000000f10b11b>] kmemleak_alloc+0x34/0x40
[<000000001cd4cf73>] __kmalloc_cache_noprof+0x26c/0x2f4
[<00000000f1f3cffa>] drm_mode_duplicate+0x44/0x19c
[<000000008cbeef13>] drm_display_mode_from_cea_vic+0x88/0x98
[<0000000019daaacf>] 0xffffffedc11ae69c
[<000000000aad0f85>] kunit_try_run_case+0x13c/0x3ac
[<00000000a9210bac>] kunit_generic_run_threadfn_adapter+0x80/0xec
[<000000000a0b2e9e>] kthread+0x2e8/0x374
[<00000000bd668858>] ret_from_fork+0x10/0x20
......
Free `mode` by using drm_kunit_display_mode_from_cea_vic()
to fix it. | CVSS 5.5 | Linux | - | Patched |  |
CVE-2024-50172In the Linux kernel, the following vulnerability has been resolved:
RDMA/bnxt_re: Fix a possible memory leak
In bnxt_re_setup_chip_ctx() when bnxt_qplib_map_db_bar() fails
driver is not freeing the memory allocated for "rdev->chip_ctx". | CVSS 5.5 | Linux | - | Patched |  |
CVE-2024-50171In the Linux kernel, the following vulnerability has been resolved:
net: systemport: fix potential memory leak in bcm_sysport_xmit()
The bcm_sysport_xmit() returns NETDEV_TX_OK without freeing skb
in case of dma_map_single() fails, add dev_kfree_skb() to fix it. | CVSS 5.5 | Linux | - | Patched |  |
CVE-2024-50170In the Linux kernel, the following vulnerability has been resolved:
net: bcmasp: fix potential memory leak in bcmasp_xmit()
The bcmasp_xmit() returns NETDEV_TX_OK without freeing skb
in case of mapping fails, add dev_kfree_skb() to fix it. | CVSS 5.5 | Linux | - | Patched |  |
CVE-2024-50168In the Linux kernel, the following vulnerability has been resolved:
net/sun3_82586: fix potential memory leak in sun3_82586_send_packet()
The sun3_82586_send_packet() returns NETDEV_TX_OK without freeing skb
in case of skb->len being too long, add dev_kfree_skb() to fix it. | CVSS 5.5 | Linux | - | Patched |  |
CVE-2024-50167In the Linux kernel, the following vulnerability has been resolved:
be2net: fix potential memory leak in be_xmit()
The be_xmit() returns NETDEV_TX_OK without freeing skb
in case of be_xmit_enqueue() fails, add dev_kfree_skb_any() to fix it. | CVSS 5.5 | Linux | - | Patched |  |
CVE-2024-50084In the Linux kernel, the following vulnerability has been resolved:
net: microchip: vcap api: Fix memory leaks in vcap_api_encode_rule_test()
Commit a3c1e45156ad ("net: microchip: vcap: Fix use-after-free error in
kunit test") fixed the use-after-free error, but introduced below
memory leaks by removing necessary vcap_free_rule(), add it to fix it.
unreferenced object 0xffffff80ca58b700 (size 192):
comm "kunit_try_catch", pid 1215, jiffies 4294898264
hex dump (first 32 bytes):
00 12 7a 00 05 00 00 00 0a 00 00 00 64 00 00 00 ..z.........d...
00 00 00 00 00 00 00 00 00 04 0b cc 80 ff ff ff ................
backtrace (crc 9c09c3fe):
[<0000000052a0be73>] kmemleak_alloc+0x34/0x40
[<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4
[<0000000040a01b8d>] vcap_alloc_rule+0x3cc/0x9c4
[<000000003fe86110>] vcap_api_encode_rule_test+0x1ac/0x16b0
[<00000000b3595fc4>] kunit_try_run_case+0x13c/0x3ac
[<0000000010f5d2bf>] kunit_generic_run_threadfn_adapter+0x80/0xec
[<00000000c5d82c9a>] kthread+0x2e8/0x374
[<00000000f4287308>] ret_from_fork+0x10/0x20
unreferenced object 0xffffff80cc0b0400 (size 64):
comm "kunit_try_catch", pid 1215, jiffies 4294898265
hex dump (first 32 bytes):
80 04 0b cc 80 ff ff ff 18 b7 58 ca 80 ff ff ff ..........X.....
39 00 00 00 02 00 00 00 06 05 04 03 02 01 ff ff 9...............
backtrace (crc daf014e9):
[<0000000052a0be73>] kmemleak_alloc+0x34/0x40
[<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4
[<000000000ff63fd4>] vcap_rule_add_key+0x2cc/0x528
[<00000000dfdb1e81>] vcap_api_encode_rule_test+0x224/0x16b0
[<00000000b3595fc4>] kunit_try_run_case+0x13c/0x3ac
[<0000000010f5d2bf>] kunit_generic_run_threadfn_adapter+0x80/0xec
[<00000000c5d82c9a>] kthread+0x2e8/0x374
[<00000000f4287308>] ret_from_fork+0x10/0x20
unreferenced object 0xffffff80cc0b0700 (size 64):
comm "kunit_try_catch", pid 1215, jiffies 4294898265
hex dump (first 32 bytes):
80 07 0b cc 80 ff ff ff 28 b7 58 ca 80 ff ff ff ........(.X.....
3c 00 00 00 00 00 00 00 01 2f 03 b3 ec ff ff ff <......../......
backtrace (crc 8d877792):
[<0000000052a0be73>] kmemleak_alloc+0x34/0x40
[<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4
[<000000006eadfab7>] vcap_rule_add_action+0x2d0/0x52c
[<00000000323475d1>] vcap_api_encode_rule_test+0x4d4/0x16b0
[<00000000b3595fc4>] kunit_try_run_case+0x13c/0x3ac
[<0000000010f5d2bf>] kunit_generic_run_threadfn_adapter+0x80/0xec
[<00000000c5d82c9a>] kthread+0x2e8/0x374
[<00000000f4287308>] ret_from_fork+0x10/0x20
unreferenced object 0xffffff80cc0b0900 (size 64):
comm "kunit_try_catch", pid 1215, jiffies 4294898266
hex dump (first 32 bytes):
80 09 0b cc 80 ff ff ff 80 06 0b cc 80 ff ff ff ................
7d 00 00 00 01 00 00 00 00 00 00 00 ff 00 00 00 }...............
backtrace (crc 34181e56):
[<0000000052a0be73>] kmemleak_alloc+0x34/0x40
[<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4
[<000000000ff63fd4>] vcap_rule_add_key+0x2cc/0x528
[<00000000991e3564>] vcap_val_rule+0xcf0/0x13e8
[<00000000fc9868e5>] vcap_api_encode_rule_test+0x678/0x16b0
[<00000000b3595fc4>] kunit_try_run_case+0x13c/0x3ac
[<0000000010f5d2bf>] kunit_generic_run_threadfn_adapter+0x80/0xec
[<00000000c5d82c9a>] kthread+0x2e8/0x374
[<00000000f4287308>] ret_from_fork+0x10/0x20
unreferenced object 0xffffff80cc0b0980 (size 64):
comm "kunit_try_catch", pid 1215, jiffies 4294898266
hex dump (first 32 bytes):
18 b7 58 ca 80 ff ff ff 00 09 0b cc 80 ff ff ff ..X.............
67 00 00 00 00 00 00 00 01 01 74 88 c0 ff ff ff g.........t.....
backtrace (crc 275fd9be):
[<0000000052a0be73>] kmemleak_alloc+0x34/0x40
[<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4
[<000000000ff63fd4>] vcap_rule_add_key+0x2cc/0x528
[<000000001396a1a2>] test_add_de
---truncated--- | CVSS 5.5 | Linux | - | Patched |  |
CVE-2024-50068In the Linux kernel, the following vulnerability has been resolved:
mm/damon/tests/sysfs-kunit.h: fix memory leak in damon_sysfs_test_add_targets()
The sysfs_target->regions allocated in damon_sysfs_regions_alloc() is not
freed in damon_sysfs_test_add_targets(), which cause the following memory
leak, free it to fix it.
unreferenced object 0xffffff80c2a8db80 (size 96):
comm "kunit_try_catch", pid 187, jiffies 4294894363
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace (crc 0):
[<0000000001e3714d>] kmemleak_alloc+0x34/0x40
[<000000008e6835c1>] __kmalloc_cache_noprof+0x26c/0x2f4
[<000000001286d9f8>] damon_sysfs_test_add_targets+0x1cc/0x738
[<0000000032ef8f77>] kunit_try_run_case+0x13c/0x3ac
[<00000000f3edea23>] kunit_generic_run_threadfn_adapter+0x80/0xec
[<00000000adf936cf>] kthread+0x2e8/0x374
[<0000000041bb1628>] ret_from_fork+0x10/0x20 | CVSS 5.5 | Linux | - | Patched |  |
CVE-2024-50064In the Linux kernel, the following vulnerability has been resolved:
zram: free secondary algorithms names
We need to kfree() secondary algorithms names when reset zram device that
had multi-streams, otherwise we leak memory.
[senozhatsky@chromium.org: kfree(NULL) is legal]
Link: https://lkml.kernel.org/r/20240917013021.868769-1-senozhatsky@chromium.org | CVSS 5.5 | Linux | - | Patched |  |
CVE-2024-50041In the Linux kernel, the following vulnerability has been resolved:
i40e: Fix macvlan leak by synchronizing access to mac_filter_hash
This patch addresses a macvlan leak issue in the i40e driver caused by
concurrent access to vsi->mac_filter_hash. The leak occurs when multiple
threads attempt to modify the mac_filter_hash simultaneously, leading to
inconsistent state and potential memory leaks.
To fix this, we now wrap the calls to i40e_del_mac_filter() and zeroing
vf->default_lan_addr.addr with spin_lock/unlock_bh(&vsi->mac_filter_hash_lock),
ensuring atomic operations and preventing concurrent access.
Additionally, we add lockdep_assert_held(&vsi->mac_filter_hash_lock) in
i40e_add_mac_filter() to help catch similar issues in the future.
Reproduction steps:
1. Spawn VFs and configure port vlan on them.
2. Trigger concurrent macvlan operations (e.g., adding and deleting
portvlan and/or mac filters).
3. Observe the potential memory leak and inconsistent state in the
mac_filter_hash.
This synchronization ensures the integrity of the mac_filter_hash and prevents
the described leak. | CVSS 5.5 | Linux | - | Patched |  |
CVE-2024-50013In the Linux kernel, the following vulnerability has been resolved:
exfat: fix memory leak in exfat_load_bitmap()
If the first directory entry in the root directory is not a bitmap
directory entry, 'bh' will not be released and reassigned, which
will cause a memory leak. | CVSS 5.5 | Linux | - | Patched |  |
CVE-2024-49975In the Linux kernel, the following vulnerability has been resolved:
uprobes: fix kernel info leak via "[uprobes]" vma
xol_add_vma() maps the uninitialized page allocated by __create_xol_area()
into userspace. On some architectures (x86) this memory is readable even
without VM_READ, VM_EXEC results in the same pgprot_t as VM_EXEC|VM_READ,
although this doesn't really matter, debugger can read this memory anyway. | CVSS 5.5 | Linux | - | Patched |  |
CVE-2024-49870In the Linux kernel, the following vulnerability has been resolved:
cachefiles: fix dentry leak in cachefiles_open_file()
A dentry leak may be caused when a lookup cookie and a cull are concurrent:
P1 | P2
-----------------------------------------------------------
cachefiles_lookup_cookie
cachefiles_look_up_object
lookup_one_positive_unlocked
// get dentry
cachefiles_cull
inode->i_flags |= S_KERNEL_FILE;
cachefiles_open_file
cachefiles_mark_inode_in_use
__cachefiles_mark_inode_in_use
can_use = false
if (!(inode->i_flags & S_KERNEL_FILE))
can_use = true
return false
return false
// Returns an error but doesn't put dentry
After that the following WARNING will be triggered when the backend folder
is umounted:
==================================================================
BUG: Dentry 000000008ad87947{i=7a,n=Dx_1_1.img} still in use (1) [unmount of ext4 sda]
WARNING: CPU: 4 PID: 359261 at fs/dcache.c:1767 umount_check+0x5d/0x70
CPU: 4 PID: 359261 Comm: umount Not tainted 6.6.0-dirty #25
RIP: 0010:umount_check+0x5d/0x70
Call Trace:
<TASK>
d_walk+0xda/0x2b0
do_one_tree+0x20/0x40
shrink_dcache_for_umount+0x2c/0x90
generic_shutdown_super+0x20/0x160
kill_block_super+0x1a/0x40
ext4_kill_sb+0x22/0x40
deactivate_locked_super+0x35/0x80
cleanup_mnt+0x104/0x160
==================================================================
Whether cachefiles_open_file() returns true or false, the reference count
obtained by lookup_positive_unlocked() in cachefiles_look_up_object()
should be released.
Therefore release that reference count in cachefiles_look_up_object() to
fix the above issue and simplify the code. | CVSS 5.5 | Linux | - | Patched |  |
CVE-2024-47755In the Linux kernel, the following vulnerability has been resolved:
nvdimm: Fix devs leaks in scan_labels()
scan_labels() leaks memory when label scanning fails and it falls back
to just creating a default "seed" namespace for userspace to configure.
Root can force the kernel to leak memory.
Allocate the minimum resources unconditionally and release them when
unneeded to avoid the memory leak.
A kmemleak reports:
unreferenced object 0xffff88800dda1980 (size 16):
comm "kworker/u10:5", pid 69, jiffies 4294671781
hex dump (first 16 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace (crc 0):
[<00000000c5dea560>] __kmalloc+0x32c/0x470
[<000000009ed43c83>] nd_region_register_namespaces+0x6fb/0x1120 [libnvdimm]
[<000000000e07a65c>] nd_region_probe+0xfe/0x210 [libnvdimm]
[<000000007b79ce5f>] nvdimm_bus_probe+0x7a/0x1e0 [libnvdimm]
[<00000000a5f3da2e>] really_probe+0xc6/0x390
[<00000000129e2a69>] __driver_probe_device+0x78/0x150
[<000000002dfed28b>] driver_probe_device+0x1e/0x90
[<00000000e7048de2>] __device_attach_driver+0x85/0x110
[<0000000032dca295>] bus_for_each_drv+0x85/0xe0
[<00000000391c5a7d>] __device_attach+0xbe/0x1e0
[<0000000026dabec0>] bus_probe_device+0x94/0xb0
[<00000000c590d936>] device_add+0x656/0x870
[<000000003d69bfaa>] nd_async_device_register+0xe/0x50 [libnvdimm]
[<000000003f4c52a4>] async_run_entry_fn+0x2e/0x110
[<00000000e201f4b0>] process_one_work+0x1ee/0x600
[<000000006d90d5a9>] worker_thread+0x183/0x350 | CVSS 5.5 | Linux | - | Patched |  |
CVE-2024-47677In the Linux kernel, the following vulnerability has been resolved:
exfat: resolve memory leak from exfat_create_upcase_table()
If exfat_load_upcase_table reaches end and returns -EINVAL,
allocated memory doesn't get freed and while
exfat_load_default_upcase_table allocates more memory, leading to a
memory leak.
Here's link to syzkaller crash report illustrating this issue:
https://syzkaller.appspot.com/text?tag=CrashReport&x=1406c201980000 | CVSS 5.5 | Linux | - | Patched |  |
CVE-2024-46779In the Linux kernel, the following vulnerability has been resolved:
drm/imagination: Free pvr_vm_gpuva after unlink
This caused a measurable memory leak. Although the individual
allocations are small, the leaks occurs in a high-usage codepath
(remapping or unmapping device memory) so they add up quickly. | CVSS 5.5 | Linux | - | Patched |  |
CVE-2024-44979In the Linux kernel, the following vulnerability has been resolved:
drm/xe: Fix missing workqueue destroy in xe_gt_pagefault
On driver reload we never free up the memory for the pagefault and
access counter workqueues. Add those destroy calls here.
(cherry picked from commit 7586fc52b14e0b8edd0d1f8a434e0de2078b7b2b) | CVSS 5.5 | Linux | - | Patched |  |
CVE-2024-44971In the Linux kernel, the following vulnerability has been resolved:
net: dsa: bcm_sf2: Fix a possible memory leak in bcm_sf2_mdio_register()
bcm_sf2_mdio_register() calls of_phy_find_device() and then
phy_device_remove() in a loop to remove existing PHY devices.
of_phy_find_device() eventually calls bus_find_device(), which calls
get_device() on the returned struct device * to increment the refcount.
The current implementation does not decrement the refcount, which causes
memory leak.
This commit adds the missing phy_device_free() call to decrement the
refcount via put_device() to balance the refcount. | CVSS 5.5 | Linux | - | Patched |  |
CVE-2024-44969In the Linux kernel, the following vulnerability has been resolved:
s390/sclp: Prevent release of buffer in I/O
When a task waiting for completion of a Store Data operation is
interrupted, an attempt is made to halt this operation. If this attempt
fails due to a hardware or firmware problem, there is a chance that the
SCLP facility might store data into buffers referenced by the original
operation at a later time.
Handle this situation by not releasing the referenced data buffers if
the halt attempt fails. For current use cases, this might result in a
leak of few pages of memory in case of a rare hardware/firmware
malfunction. | CVSS 5.5 | Linux | - | Patched |  |
CVE-2024-44964In the Linux kernel, the following vulnerability has been resolved:
idpf: fix memory leaks and crashes while performing a soft reset
The second tagged commit introduced a UAF, as it removed restoring
q_vector->vport pointers after reinitializating the structures.
This is due to that all queue allocation functions are performed here
with the new temporary vport structure and those functions rewrite
the backpointers to the vport. Then, this new struct is freed and
the pointers start leading to nowhere.
But generally speaking, the current logic is very fragile. It claims
to be more reliable when the system is low on memory, but in fact, it
consumes two times more memory as at the moment of running this
function, there are two vports allocated with their queues and vectors.
Moreover, it claims to prevent the driver from running into "bad state",
but in fact, any error during the rebuild leaves the old vport in the
partially allocated state.
Finally, if the interface is down when the function is called, it always
allocates a new queue set, but when the user decides to enable the
interface later on, vport_open() allocates them once again, IOW there's
a clear memory leak here.
Just don't allocate a new queue set when performing a reset, that solves
crashes and memory leaks. Readd the old queue number and reopen the
interface on rollback - that solves limbo states when the device is left
disabled and/or without HW queues enabled. | CVSS 7.8 | Linux | - | Patched |  |
CVE-2024-44944In the Linux kernel, the following vulnerability has been resolved:
netfilter: ctnetlink: use helper function to calculate expect ID
Delete expectation path is missing a call to the nf_expect_get_id()
helper function to calculate the expectation ID, otherwise LSB of the
expectation object address is leaked to userspace. | CVSS 5.5 | Linux | - | Patched |  |
CVE-2024-4435When storing unbounded types in a BTreeMap, a node is represented as a linked list of "memory chunks". It was discovered recently that when we deallocate a node, in some cases only the first memory chunk is deallocated, and the rest of the memory chunks remain (incorrectly) allocated, causing a memory leak. In the worst case, depending on how a canister uses the BTreeMap, an adversary could interact with the canister through its API and trigger interactions with the map that keep consuming memory due to the memory leak. This could potentially lead to using an excessive amount of memory, or even running out of memory.
This issue has been fixed in #212 https://github.com/dfinity/stable-structures/pull/212 by changing the logic for deallocating nodes to ensure that all of a node's memory chunks are deallocated and users are asked to upgrade to version 0.6.4.. Tests have been added to prevent regressions of this nature moving forward. Note: Users of stable-structure < 0.6.0 are not affected.
Users who are not storing unbounded types in BTreeMap are not affected and do not need to upgrade. Otherwise, an upgrade to version 0.6.4 is necessary. | CVSS 5.9 | - | Patched |  | |
CVE-2024-43913In the Linux kernel, the following vulnerability has been resolved:
nvme: apple: fix device reference counting
Drivers must call nvme_uninit_ctrl after a successful nvme_init_ctrl.
Split the allocation side out to make the error handling boundary easier
to navigate. The apple driver had been doing this wrong, leaking the
controller device memory on a tagset failure. | CVSS 5.5 | Linux | - | Patched |  |
CVE-2024-43871In the Linux kernel, the following vulnerability has been resolved:
devres: Fix memory leakage caused by driver API devm_free_percpu()
It will cause memory leakage when use driver API devm_free_percpu()
to free memory allocated by devm_alloc_percpu(), fixed by using
devres_release() instead of devres_destroy() within devm_free_percpu(). | CVSS 5.5 | Linux | - | Patched |  |
CVE-2024-43861In the Linux kernel, the following vulnerability has been resolved:
net: usb: qmi_wwan: fix memory leak for not ip packets
Free the unused skb when not ip packets arrive. | CVSS 5.5 | Linux | - | Patched |  |
CVE-2024-43854In the Linux kernel, the following vulnerability has been resolved:
block: initialize integrity buffer to zero before writing it to media
Metadata added by bio_integrity_prep is using plain kmalloc, which leads
to random kernel memory being written media. For PI metadata this is
limited to the app tag that isn't used by kernel generated metadata,
but for non-PI metadata the entire buffer leaks kernel memory.
Fix this by adding the __GFP_ZERO flag to allocations for writes. | CVSS 5.5 | Linux | - | Patched |  |
CVE-2024-43696in OpenHarmony v4.1.0 and prior versions allow a local attacker cause DOS by memory leak. | CVSS 5.5 | Openatom, et al | - | - |  |
CVE-2024-42477llama.cpp provides LLM inference in C/C++. The unsafe `type` member in the `rpc_tensor` structure can cause `global-buffer-overflow`. This vulnerability may lead to memory data leakage. The vulnerability is fixed in b3561. | CVSS 7.5 | - | Patched |  | |
CVE-2024-42263In the Linux kernel, the following vulnerability has been resolved:
drm/v3d: Fix potential memory leak in the timestamp extension
If fetching of userspace memory fails during the main loop, all drm sync
objs looked up until that point will be leaked because of the missing
drm_syncobj_put.
Fix it by exporting and using a common cleanup helper.
(cherry picked from commit 753ce4fea62182c77e1691ab4f9022008f25b62e) | CVSS 5.5 | Linux | - | Patched |  |
CVE-2024-42262In the Linux kernel, the following vulnerability has been resolved:
drm/v3d: Fix potential memory leak in the performance extension
If fetching of userspace memory fails during the main loop, all drm sync
objs looked up until that point will be leaked because of the missing
drm_syncobj_put.
Fix it by exporting and using a common cleanup helper.
(cherry picked from commit 484de39fa5f5b7bd0c5f2e2c5265167250ef7501) | CVSS 5.5 | Linux | - | Patched |  |
CVE-2024-42152In the Linux kernel, the following vulnerability has been resolved:
nvmet: fix a possible leak when destroy a ctrl during qp establishment
In nvmet_sq_destroy we capture sq->ctrl early and if it is non-NULL we
know that a ctrl was allocated (in the admin connect request handler)
and we need to release pending AERs, clear ctrl->sqs and sq->ctrl
(for nvme-loop primarily), and drop the final reference on the ctrl.
However, a small window is possible where nvmet_sq_destroy starts (as
a result of the client giving up and disconnecting) concurrently with
the nvme admin connect cmd (which may be in an early stage). But *before*
kill_and_confirm of sq->ref (i.e. the admin connect managed to get an sq
live reference). In this case, sq->ctrl was allocated however after it was
captured in a local variable in nvmet_sq_destroy.
This prevented the final reference drop on the ctrl.
Solve this by re-capturing the sq->ctrl after all inflight request has
completed, where for sure sq->ctrl reference is final, and move forward
based on that.
This issue was observed in an environment with many hosts connecting
multiple ctrls simoutanuosly, creating a delay in allocating a ctrl
leading up to this race window. | CVSS 4.7 | Linux | - | Patched |  |
CVE-2024-42070In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: fully validate NFT_DATA_VALUE on store to data registers
register store validation for NFT_DATA_VALUE is conditional, however,
the datatype is always either NFT_DATA_VALUE or NFT_DATA_VERDICT. This
only requires a new helper function to infer the register type from the
set datatype so this conditional check can be removed. Otherwise,
pointer to chain object can be leaked through the registers. | CVSS 5.5 | Linux | - | Patched |  |
CVE-2024-41172In versions of Apache CXF before 3.6.4 and 4.0.5 (3.5.x and lower versions are not impacted), a CXF HTTP client conduit may prevent HTTPClient instances from being garbage collected and it is possible that memory consumption will continue to increase, eventually causing the application to run out of memory
| CVSS 7.5 | Apache | - | Patched |  |
CVE-2024-41076In the Linux kernel, the following vulnerability has been resolved:
NFSv4: Fix memory leak in nfs4_set_security_label
We leak nfs_fattr and nfs4_label every time we set a security xattr. | CVSS 5.5 | Linux | - | Patched |  |
CVE-2024-41066In the Linux kernel, the following vulnerability has been resolved:
ibmvnic: Add tx check to prevent skb leak
Below is a summary of how the driver stores a reference to an skb during
transmit:
tx_buff[free_map[consumer_index]]->skb = new_skb;
free_map[consumer_index] = IBMVNIC_INVALID_MAP;
consumer_index ++;
Where variable data looks like this:
free_map == [4, IBMVNIC_INVALID_MAP, IBMVNIC_INVALID_MAP, 0, 3]
consumer_index^
tx_buff == [skb=null, skb=<ptr>, skb=<ptr>, skb=null, skb=null]
The driver has checks to ensure that free_map[consumer_index] pointed to
a valid index but there was no check to ensure that this index pointed
to an unused/null skb address. So, if, by some chance, our free_map and
tx_buff lists become out of sync then we were previously risking an
skb memory leak. This could then cause tcp congestion control to stop
sending packets, eventually leading to ETIMEDOUT.
Therefore, add a conditional to ensure that the skb address is null. If
not then warn the user (because this is still a bug that should be
patched) and free the old pointer to prevent memleak/tcp problems. | CVSS 5.5 | Linux | - | Patched |  |
CVE-2024-41006In the Linux kernel, the following vulnerability has been resolved:
netrom: Fix a memory leak in nr_heartbeat_expiry()
syzbot reported a memory leak in nr_create() [0].
Commit 409db27e3a2e ("netrom: Fix use-after-free of a listening socket.")
added sock_hold() to the nr_heartbeat_expiry() function, where
a) a socket has a SOCK_DESTROY flag or
b) a listening socket has a SOCK_DEAD flag.
But in the case "a," when the SOCK_DESTROY flag is set, the file descriptor
has already been closed and the nr_release() function has been called.
So it makes no sense to hold the reference count because no one will
call another nr_destroy_socket() and put it as in the case "b."
nr_connect
nr_establish_data_link
nr_start_heartbeat
nr_release
switch (nr->state)
case NR_STATE_3
nr->state = NR_STATE_2
sock_set_flag(sk, SOCK_DESTROY);
nr_rx_frame
nr_process_rx_frame
switch (nr->state)
case NR_STATE_2
nr_state2_machine()
nr_disconnect()
nr_sk(sk)->state = NR_STATE_0
sock_set_flag(sk, SOCK_DEAD)
nr_heartbeat_expiry
switch (nr->state)
case NR_STATE_0
if (sock_flag(sk, SOCK_DESTROY) ||
(sk->sk_state == TCP_LISTEN
&& sock_flag(sk, SOCK_DEAD)))
sock_hold() // ( !!! )
nr_destroy_socket()
To fix the memory leak, let's call sock_hold() only for a listening socket.
Found by InfoTeCS on behalf of Linux Verification Center
(linuxtesting.org) with Syzkaller.
[0]: https://syzkaller.appspot.com/bug?extid=d327a1f3b12e1e206c16 | CVSS 5.5 | Linux | - | Patched |  |
CVE-2024-41002In the Linux kernel, the following vulnerability has been resolved:
crypto: hisilicon/sec - Fix memory leak for sec resource release
The AIV is one of the SEC resources. When releasing resources,
it need to release the AIV resources at the same time.
Otherwise, memory leakage occurs.
The aiv resource release is added to the sec resource release
function. | CVSS 5.5 | Linux | - | Patched |  |
CVE-2024-41001In the Linux kernel, the following vulnerability has been resolved:
io_uring/sqpoll: work around a potential audit memory leak
kmemleak complains that there's a memory leak related to connect
handling:
unreferenced object 0xffff0001093bdf00 (size 128):
comm "iou-sqp-455", pid 457, jiffies 4294894164
hex dump (first 32 bytes):
02 00 fa ea 7f 00 00 01 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace (crc 2e481b1a):
[<00000000c0a26af4>] kmemleak_alloc+0x30/0x38
[<000000009c30bb45>] kmalloc_trace+0x228/0x358
[<000000009da9d39f>] __audit_sockaddr+0xd0/0x138
[<0000000089a93e34>] move_addr_to_kernel+0x1a0/0x1f8
[<000000000b4e80e6>] io_connect_prep+0x1ec/0x2d4
[<00000000abfbcd99>] io_submit_sqes+0x588/0x1e48
[<00000000e7c25e07>] io_sq_thread+0x8a4/0x10e4
[<00000000d999b491>] ret_from_fork+0x10/0x20
which can can happen if:
1) The command type does something on the prep side that triggers an
audit call.
2) The thread hasn't done any operations before this that triggered
an audit call inside ->issue(), where we have audit_uring_entry()
and audit_uring_exit().
Work around this by issuing a blanket NOP operation before the SQPOLL
does anything. | CVSS 5.5 | Linux | - | Patched |  |
CVE-2024-40997In the Linux kernel, the following vulnerability has been resolved:
cpufreq: amd-pstate: fix memory leak on CPU EPP exit
The cpudata memory from kzalloc() in amd_pstate_epp_cpu_init() is
not freed in the analogous exit function, so fix that.
[ rjw: Subject and changelog edits ] | CVSS 5.5 | Linux | - | Patched |  |
CVE-2024-40934In the Linux kernel, the following vulnerability has been resolved:
HID: logitech-dj: Fix memory leak in logi_dj_recv_switch_to_dj_mode()
Fix a memory leak on logi_dj_recv_send_report() error path. | CVSS 5.5 | Linux | - | Patched |  |
CVE-2024-40932In the Linux kernel, the following vulnerability has been resolved:
drm/exynos/vidi: fix memory leak in .get_modes()
The duplicated EDID is never freed. Fix it. | CVSS 5.5 | Linux | - | Patched |  |
CVE-2024-39550A Missing Release of Memory after Effective Lifetime vulnerability in the rtlogd process of Juniper Networks Junos OS on MX Series with SPC3 allows an unauthenticated, adjacent attacker to trigger internal events cause ( which can be done by repeated port flaps) to cause a slow memory leak, ultimately leading to a Denial of Service (DoS).
Memory can only be recovered by manually restarting rtlogd process.
The memory usage can be monitored using the below command.
user@host> show system processes extensive | match rtlog
This issue affects Junos OS on MX Series with SPC3 line card:
* from 21.2R3 before 21.2R3-S8,
* from 21.4R2 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-S1,
* from 23.2 before 23.2R2,
* from 23.4 before 23.4R2. | CVSS 6.5 | Juniper | - | - |  |
CVE-2024-39549A Missing Release of Memory after Effective Lifetime vulnerability in the routing process daemon (rpd) of Juniper Networks Junos OS and Junos OS Evolved allows an attacker to send a malformed BGP Path attribute update which allocates memory used to log the bad path attribute. This memory is not properly freed in all circumstances, leading to a Denial of Service (DoS).
Consumed memory can be freed by manually restarting Routing Protocol Daemon (rpd).
Memory utilization could be monitored by:
user@host> show system memory or show system monitor memory status
This issue affects:
Junos OS: * All versions before 21.2R3-S8,
* from 21.4 before 21.4R3-S8,
* from 22.2 before 22.2R3-S4,
* from 22.3 before 22.3R3-S3,
* from 22.4 before 22.4R3-S3,
* from 23.2 before 23.2R2-S1,
* from 23.4 before 23.4R1-S2, 23.4R2,
* from 24.2 before 24.2R2-EVO.
Junos OS Evolved:
* All versions before 21.2R3-S8-EVO,
* from 21.4 before 21.4R3-S8-EVO,
* from 22.2 before 22.2R3-S4-EVO,
* from 22.3 before 22.3R3-S3-EVO,
* from 22.4 before 22.4R3-S3-EVO,
* from 23.2 before 23.2R2-S1-EVO,
* from 23.4 before 23.4R1-S2, 23.4R2,
* from 24.2 before 24.2R2-EVO. | CVSS 7.5 | Juniper | - | Patched |  |
CVE-2024-39539A Missing Release of Memory after Effective Lifetime vulnerability in Juniper Networks Junos OS on MX Series allows an unauthenticated adjacent attacker to cause a Denial-of-Service (DoS).
In a subscriber management scenario continuous subscriber logins will trigger a memory leak and eventually lead to an FPC crash and restart.
This issue affects Junos OS on MX Series:
* All version before 21.2R3-S6,
* 21.4 versions before 21.4R3-S6,
* 22.1 versions before 22.1R3-S5,
* 22.2 versions before 22.2R3-S3,
* 22.3 versions before 22.3R3-S2,
* 22.4 versions before 22.4R3,
* 23.2 versions before 23.2R2. | CVSS 5.3 | Juniper | - | - |  |
CVE-2024-39536A Missing Release of Memory after Effective Lifetime vulnerability in the Periodic Packet Management Daemon (ppmd) of Juniper Networks Junos OS and Junos OS Evolved allows an unauthenticated adjacent attacker to cause a
Denial-of-Service (DoS).
When a BFD session configured with authentication flaps, ppmd memory can leak. Whether the leak happens depends on a race condition which is outside the attackers control. This issue only affects BFD operating in distributed aka delegated (which is the default behavior) or inline mode.
Whether the leak occurs can be monitored with the following CLI command:
> show ppm request-queue
FPC Pending-request
fpc0 2
request-total-pending: 2
where a continuously increasing number of pending requests is indicative of the leak.
This issue affects:
Junos OS:
* All versions before 21.2R3-S8,
* 21.4 versions before 21.4R3-S7,
* 22.1 versions before 22.1R3-S4,
* 22.2 versions before 22.2R3-S4,
* 22.3 versions before 22.3R3,
* 22.4 versions before 22.4R2-S2, 22.4R3,
* 23.1 versions before 23.1R2.
Junos OS Evolved:
* All versions before 21.2R3-S8-EVO,
* 21.4-EVO versions before 21.4R3-S7-EVO,
* 22.2-EVO versions before 22.2R3-S4-EVO,
* 22.3-EVO versions before 22.3R3-EVO,
* 22.4-EVO versions before 22.4R3-EVO,
* 23.2-EVO versions before 23.2R1-EVO. | CVSS 5.3 | Juniper | - | - |  |
CVE-2024-39493In the Linux kernel, the following vulnerability has been resolved:
crypto: qat - Fix ADF_DEV_RESET_SYNC memory leak
Using completion_done to determine whether the caller has gone
away only works after a complete call. Furthermore it's still
possible that the caller has not yet called wait_for_completion,
resulting in another potential UAF.
Fix this by making the caller use cancel_work_sync and then freeing
the memory safely. | CVSS 5.5 | Linux | - | Patched |  |
CVE-2024-39489In the Linux kernel, the following vulnerability has been resolved:
ipv6: sr: fix memleak in seg6_hmac_init_algo
seg6_hmac_init_algo returns without cleaning up the previous allocations
if one fails, so it's going to leak all that memory and the crypto tfms.
Update seg6_hmac_exit to only free the memory when allocated, so we can
reuse the code directly. | CVSS 5.5 | Linux | - | Patched |  |
CVE-2024-38632In the Linux kernel, the following vulnerability has been resolved:
vfio/pci: fix potential memory leak in vfio_intx_enable()
If vfio_irq_ctx_alloc() failed will lead to 'name' memory leak. | CVSS 5.5 | Linux | - | Patched |  |
CVE-2024-38603In the Linux kernel, the following vulnerability has been resolved:
drivers/perf: hisi: hns3: Actually use devm_add_action_or_reset()
pci_alloc_irq_vectors() allocates an irq vector. When devm_add_action()
fails, the irq vector is not freed, which leads to a memory leak.
Replace the devm_add_action with devm_add_action_or_reset to ensure
the irq vector can be destroyed when it fails. | CVSS 5.5 | Linux | - | Patched |  |
CVE-2024-38563In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: mt7996: fix potential memory leakage when reading chip temperature
Without this commit, reading chip temperature will cause memory leakage. | CVSS 5.5 | Linux | - | Patched |  |
CVE-2024-38539In the Linux kernel, the following vulnerability has been resolved:
RDMA/cma: Fix kmemleak in rdma_core observed during blktests nvme/rdma use siw
When running blktests nvme/rdma, the following kmemleak issue will appear.
kmemleak: Kernel memory leak detector initialized (mempool available:36041)
kmemleak: Automatic memory scanning thread started
kmemleak: 2 new suspected memory leaks (see /sys/kernel/debug/kmemleak)
kmemleak: 8 new suspected memory leaks (see /sys/kernel/debug/kmemleak)
kmemleak: 17 new suspected memory leaks (see /sys/kernel/debug/kmemleak)
kmemleak: 4 new suspected memory leaks (see /sys/kernel/debug/kmemleak)
unreferenced object 0xffff88855da53400 (size 192):
comm "rdma", pid 10630, jiffies 4296575922
hex dump (first 32 bytes):
37 00 00 00 00 00 00 00 c0 ff ff ff 1f 00 00 00 7...............
10 34 a5 5d 85 88 ff ff 10 34 a5 5d 85 88 ff ff .4.].....4.]....
backtrace (crc 47f66721):
[<ffffffff911251bd>] kmalloc_trace+0x30d/0x3b0
[<ffffffffc2640ff7>] alloc_gid_entry+0x47/0x380 [ib_core]
[<ffffffffc2642206>] add_modify_gid+0x166/0x930 [ib_core]
[<ffffffffc2643468>] ib_cache_update.part.0+0x6d8/0x910 [ib_core]
[<ffffffffc2644e1a>] ib_cache_setup_one+0x24a/0x350 [ib_core]
[<ffffffffc263949e>] ib_register_device+0x9e/0x3a0 [ib_core]
[<ffffffffc2a3d389>] 0xffffffffc2a3d389
[<ffffffffc2688cd8>] nldev_newlink+0x2b8/0x520 [ib_core]
[<ffffffffc2645fe3>] rdma_nl_rcv_msg+0x2c3/0x520 [ib_core]
[<ffffffffc264648c>]
rdma_nl_rcv_skb.constprop.0.isra.0+0x23c/0x3a0 [ib_core]
[<ffffffff9270e7b5>] netlink_unicast+0x445/0x710
[<ffffffff9270f1f1>] netlink_sendmsg+0x761/0xc40
[<ffffffff9249db29>] __sys_sendto+0x3a9/0x420
[<ffffffff9249dc8c>] __x64_sys_sendto+0xdc/0x1b0
[<ffffffff92db0ad3>] do_syscall_64+0x93/0x180
[<ffffffff92e00126>] entry_SYSCALL_64_after_hwframe+0x71/0x79
The root cause: rdma_put_gid_attr is not called when sgid_attr is set
to ERR_PTR(-ENODEV). | CVSS 5.5 | Linux | - | Patched |  |
CVE-2024-36967In the Linux kernel, the following vulnerability has been resolved:
KEYS: trusted: Fix memory leak in tpm2_key_encode()
'scratch' is never freed. Fix this by calling kfree() in the success, and
in the error case. | CVSS 5.5 | Linux | - | Patched |  |
CVE-2024-3653A vulnerability was found in Undertow. This issue requires enabling the learning-push handler in the server's config, which is disabled by default, leaving the maxAge config in the handler unconfigured. The default is -1, which makes the handler vulnerable. If someone overwrites that config, the server is not subject to the attack. The attacker needs to be able to reach the server with a normal HTTP request. | CVSS 5.3 | Netapp | - | Patched |  |
CVE-2024-35978In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: Fix memory leak in hci_req_sync_complete()
In 'hci_req_sync_complete()', always free the previous sync
request state before assigning reference to a new one. | CVSS 5.5 | Linux | - | Patched |  |
CVE-2024-35972In the Linux kernel, the following vulnerability has been resolved:
bnxt_en: Fix possible memory leak in bnxt_rdma_aux_device_init()
If ulp = kzalloc() fails, the allocated edev will leak because it is
not properly assigned and the cleanup path will not be able to free it.
Fix it by assigning it properly immediately after allocation. | CVSS 5.5 | Linux | - | Patched |  |
CVE-2024-27508Atheme 7.2.12 contains a memory leak vulnerability in /atheme/src/crypto-benchmark/main.c. | CVSS 7.5 | Atheme | - | - |  |
CVE-2024-27507libLAS 1.8.1 contains a memory leak vulnerability in /libLAS/apps/ts2las.cpp. | CVSS 7.5 | Liblas | - | Patched |  |
CVE-2024-27012In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: restore set elements when delete set fails
From abort path, nft_mapelem_activate() needs to restore refcounters to
the original state. Currently, it uses the set->ops->walk() to iterate
over these set elements. The existing set iterator skips inactive
elements in the next generation, this does not work from the abort path
to restore the original state since it has to skip active elements
instead (not inactive ones).
This patch moves the check for inactive elements to the set iterator
callback, then it reverses the logic for the .activate case which
needs to skip active elements.
Toggle next generation bit for elements when delete set command is
invoked and call nft_clear() from .activate (abort) path to restore the
next generation bit.
The splat below shows an object in mappings memleak:
[43929.457523] ------------[ cut here ]------------
[43929.457532] WARNING: CPU: 0 PID: 1139 at include/net/netfilter/nf_tables.h:1237 nft_setelem_data_deactivate+0xe4/0xf0 [nf_tables]
[...]
[43929.458014] RIP: 0010:nft_setelem_data_deactivate+0xe4/0xf0 [nf_tables]
[43929.458076] Code: 83 f8 01 77 ab 49 8d 7c 24 08 e8 37 5e d0 de 49 8b 6c 24 08 48 8d 7d 50 e8 e9 5c d0 de 8b 45 50 8d 50 ff 89 55 50 85 c0 75 86 <0f> 0b eb 82 0f 0b eb b3 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90
[43929.458081] RSP: 0018:ffff888140f9f4b0 EFLAGS: 00010246
[43929.458086] RAX: 0000000000000000 RBX: ffff8881434f5288 RCX: dffffc0000000000
[43929.458090] RDX: 00000000ffffffff RSI: ffffffffa26d28a7 RDI: ffff88810ecc9550
[43929.458093] RBP: ffff88810ecc9500 R08: 0000000000000001 R09: ffffed10281f3e8f
[43929.458096] R10: 0000000000000003 R11: ffff0000ffff0000 R12: ffff8881434f52a0
[43929.458100] R13: ffff888140f9f5f4 R14: ffff888151c7a800 R15: 0000000000000002
[43929.458103] FS: 00007f0c687c4740(0000) GS:ffff888390800000(0000) knlGS:0000000000000000
[43929.458107] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[43929.458111] CR2: 00007f58dbe5b008 CR3: 0000000123602005 CR4: 00000000001706f0
[43929.458114] Call Trace:
[43929.458118] <TASK>
[43929.458121] ? __warn+0x9f/0x1a0
[43929.458127] ? nft_setelem_data_deactivate+0xe4/0xf0 [nf_tables]
[43929.458188] ? report_bug+0x1b1/0x1e0
[43929.458196] ? handle_bug+0x3c/0x70
[43929.458200] ? exc_invalid_op+0x17/0x40
[43929.458211] ? nft_setelem_data_deactivate+0xd7/0xf0 [nf_tables]
[43929.458271] ? nft_setelem_data_deactivate+0xe4/0xf0 [nf_tables]
[43929.458332] nft_mapelem_deactivate+0x24/0x30 [nf_tables]
[43929.458392] nft_rhash_walk+0xdd/0x180 [nf_tables]
[43929.458453] ? __pfx_nft_rhash_walk+0x10/0x10 [nf_tables]
[43929.458512] ? rb_insert_color+0x2e/0x280
[43929.458520] nft_map_deactivate+0xdc/0x1e0 [nf_tables]
[43929.458582] ? __pfx_nft_map_deactivate+0x10/0x10 [nf_tables]
[43929.458642] ? __pfx_nft_mapelem_deactivate+0x10/0x10 [nf_tables]
[43929.458701] ? __rcu_read_unlock+0x46/0x70
[43929.458709] nft_delset+0xff/0x110 [nf_tables]
[43929.458769] nft_flush_table+0x16f/0x460 [nf_tables]
[43929.458830] nf_tables_deltable+0x501/0x580 [nf_tables] | CVSS 5.5 | Fedoraproject, et al | - | Patched |  |
CVE-2024-26986In the Linux kernel, the following vulnerability has been resolved:
drm/amdkfd: Fix memory leak in create_process failure
Fix memory leak due to a leaked mmget reference on an error handling
code path that is triggered when attempting to create KFD processes
while a GPU reset is in progress. | CVSS 5.5 | Fedoraproject, et al | - | Patched |  |
CVE-2024-26912In the Linux kernel, the following vulnerability has been resolved:
drm/nouveau: fix several DMA buffer leaks
Nouveau manages GSP-RM DMA buffers with nvkm_gsp_mem objects. Several of
these buffers are never dealloced. Some of them can be deallocated
right after GSP-RM is initialized, but the rest need to stay until the
driver unloads.
Also futher bullet-proof these objects by poisoning the buffer and
clearing the nvkm_gsp_mem object when it is deallocated. Poisoning
the buffer should trigger an error (or crash) from GSP-RM if it tries
to access the buffer after we've deallocated it, because we were wrong
about when it is safe to deallocate.
Finally, change the mem->size field to a size_t because that's the same
type that dma_alloc_coherent expects. | CVSS 5.5 | Linux | - | Patched |  |
CVE-2024-26900In the Linux kernel, the following vulnerability has been resolved:
md: fix kmemleak of rdev->serial
If kobject_add() is fail in bind_rdev_to_array(), 'rdev->serial' will be
alloc not be freed, and kmemleak occurs.
unreferenced object 0xffff88815a350000 (size 49152):
comm "mdadm", pid 789, jiffies 4294716910
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace (crc f773277a):
[<0000000058b0a453>] kmemleak_alloc+0x61/0xe0
[<00000000366adf14>] __kmalloc_large_node+0x15e/0x270
[<000000002e82961b>] __kmalloc_node.cold+0x11/0x7f
[<00000000f206d60a>] kvmalloc_node+0x74/0x150
[<0000000034bf3363>] rdev_init_serial+0x67/0x170
[<0000000010e08fe9>] mddev_create_serial_pool+0x62/0x220
[<00000000c3837bf0>] bind_rdev_to_array+0x2af/0x630
[<0000000073c28560>] md_add_new_disk+0x400/0x9f0
[<00000000770e30ff>] md_ioctl+0x15bf/0x1c10
[<000000006cfab718>] blkdev_ioctl+0x191/0x3f0
[<0000000085086a11>] vfs_ioctl+0x22/0x60
[<0000000018b656fe>] __x64_sys_ioctl+0xba/0xe0
[<00000000e54e675e>] do_syscall_64+0x71/0x150
[<000000008b0ad622>] entry_SYSCALL_64_after_hwframe+0x6c/0x74 | CVSS 5.5 | Linux | - | Patched |  |
CVE-2024-26655In the Linux kernel, the following vulnerability has been resolved:
Fix memory leak in posix_clock_open()
If the clk ops.open() function returns an error, we don't release the
pccontext we allocated for this clock.
Re-organize the code slightly to make it all more obvious. | CVSS Low | Linux | - | Patched |  |
CVE-2024-26462A memory leak flaw was found in krb5 in /krb5/src/kdc/ndr.c. This issue can lead to a denial of service through memory exhaustion. | CVSS MEDIUM | Mit | - | Patched |  |
CVE-2024-26461A memory leak flaw was found in krb5 in /krb5/src/lib/gssapi/krb5/k5sealv3.c. This issue can lead to a denial of service through memory exhaustion. | CVSS 7.5 | Mit | - | Patched |  |
CVE-2024-26458Kerberos 5 (aka krb5) 1.21.2 contains a memory leak in /krb5/src/lib/rpc/pmap_rmt.c. | CVSS MEDIUM | Mit | - | Patched |  |
CVE-2024-25770libming 0.4.8 contains a memory leak vulnerability in /libming/src/actioncompiler/listaction.c. | CVSS 4.3 | Libming | - | - |  |
CVE-2024-25740A memory leak flaw was found in the UBI driver in drivers/mtd/ubi/attach.c in the Linux kernel through 6.7.4 for UBI_IOCATT, because kobj->name is not released. | CVSS 5.5 | Linux | - | Patched |  |
CVE-2024-24267gpac v2.2.1 was discovered to contain a memory leak via the gfio_blob variable in the gf_fileio_from_blob function. | CVSS 7.5 | Gpac | Exploit | - |  |
CVE-2024-24265gpac v2.2.1 was discovered to contain a memory leak via the dst_props variable in the gf_filter_pid_merge_properties_internal function. | CVSS 7.5 | Gpac | Exploit | - |  |
CVE-2024-24259A memory leak flaw was found in the glutAddMenuEntry function of freeglut, an open-source alternative to the OpenGL Utility Toolkit. This issue may allow an attacker to launch a denial of service attack by crashing or hanging the program or take advantage of other unexpected program behavior resulting from a low memory condition. | CVSS 7.5 | Artifex | Exploit | Patched |  |
CVE-2024-24258A memory leak flaw was found in the glutAddSubMenu function of freeglut, an open-source alternative to the OpenGL Utility Toolkit. This flaw allows an attacker to launch a denial of service attack by crashing or hanging the program or taking advantage of other unexpected program behavior resulting from a low memory condition. | CVSS 7.5 | Artifex | Exploit | Patched |  |
CVE-2024-24155Bento4 v1.5.1-628 contains a Memory leak on AP4_Movie::AP4_Movie, parsing tracks and added into m_Tracks list, but mp42aac cannot correctly delete when we got an no audio track found error. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted mp4 file. | CVSS 6.5 | Axiosys | - | - |  |
CVE-2024-24150A memory leak issue discovered in parseSWF_TEXTRECORD in libming v0.4.8 allows attackers to cause a denial of service via a crafted SWF file. | CVSS 6.5 | Libming | Exploit | - |  |
CVE-2024-24149A memory leak issue discovered in parseSWF_GLYPHENTRY in libming v0.4.8 allows attackers to cause a denial of service via a crafted SWF file. | CVSS 6.5 | Libming | Exploit | - |  |
CVE-2024-24148A memory leak issue discovered in parseSWF_FREECHARACTER in libming v0.4.8 allows attackers to cause a denial of service via a crafted SWF file. | CVSS 7.5 | Libming | - | - |  |
CVE-2024-24147A memory leak issue discovered in parseSWF_FILLSTYLEARRAY in libming v0.4.8 allows attackers to cause s denial of service via a crafted SWF file. | CVSS 6.5 | Libming | Exploit | - |  |
CVE-2024-24146A memory leak issue discovered in parseSWF_DEFINEBUTTON in libming v0.4.8 allows attackers to cause s denial of service via a crafted SWF file. | CVSS 6.5 | Libming | Exploit | - |  |
CVE-2024-23820OpenFGA, an authorization/permission engine, is vulnerable to a denial of service attack in versions prior to 1.4.3. In some scenarios that depend on the model and tuples used, a call to `ListObjects` may not release memory properly. So when a sufficiently high number of those calls are executed, the OpenFGA server can create an `out of memory` error and terminate. Version 1.4.3 contains a patch for this issue. | CVSS 6.5 | Openfga | - | Patched |  |
CVE-2024-22563openvswitch 2.17.8 was discovered to contain a memory leak via the function xmalloc__ in openvswitch-2.17.8/lib/util.c. | CVSS 7.5 | Openvswitch | - | - |  |
CVE-2024-21613
A Missing Release of Memory after Effective Lifetime vulnerability in Routing Protocol Daemon (RPD) of Juniper Networks Junos OS and Junos OS Evolved allows an unauthenticated, adjacent attacker to cause an rpd crash, leading to Denial of Service (DoS).
On all Junos OS and Junos OS Evolved platforms, when traffic engineering is enabled for OSPF or ISIS, and a link flaps, a patroot memory leak is observed. This memory leak, over time, will lead to an rpd crash and restart.
The memory usage can be monitored using the below command.
user@host> show task memory detail | match patroot
This issue affects:
Juniper Networks Junos OS
* All versions earlier than 21.2R3-S3;
* 21.3 versions earlier than 21.3R3-S5;
* 21.4 versions earlier than 21.4R3-S3;
* 22.1 versions earlier than 22.1R3;
* 22.2 versions earlier than 22.2R3.
Juniper Networks Junos OS Evolved
* All versions earlier than 21.3R3-S5-EVO;
* 21.4 versions earlier than 21.4R3-EVO;
* 22.1 versions earlier than 22.1R3-EVO;
* 22.2 versions earlier than 22.2R3-EVO.
| CVSS 6.5 | Juniper | - | Patched |  |
CVE-2024-21611
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 an unauthenticated, network-based attacker to cause a Denial of Service (DoS).
In a Juniper Flow Monitoring (jflow) scenario route churn that causes BGP next hops to be updated will cause a slow memory leak and eventually a crash and restart of rpd.
Thread level memory utilization for the areas where the leak occurs can be checked using the below command:
user@host> show task memory detail | match so_in
so_in6 28 32 344450 11022400 344760 11032320
so_in 8 16 1841629 29466064 1841734 29467744
This issue affects:
Junos OS
* 21.4 versions earlier than 21.4R3;
* 22.1 versions earlier than 22.1R3;
* 22.2 versions earlier than 22.2R3.
Junos OS Evolved
* 21.4-EVO versions earlier than 21.4R3-EVO;
* 22.1-EVO versions earlier than 22.1R3-EVO;
* 22.2-EVO versions earlier than 22.2R3-EVO.
This issue does not affect:
Juniper Networks Junos OS versions earlier than 21.4R1.
Juniper Networks Junos OS Evolved versions earlier than 21.4R1.
| CVSS 7.5 | Juniper | - | Patched |  |
CVE-2024-21609A Missing Release of Memory after Effective Lifetime vulnerability in the IKE daemon (iked) of Juniper Networks Junos OS on MX Series with SPC3, and SRX Series allows an administratively adjacent attacker which is able to successfully establish IPsec tunnels to cause a Denial of Service (DoS).
If specific values for the IPsec parameters local-ip, remote-ip, remote ike-id, and traffic selectors are sent from the peer, a memory leak occurs during every IPsec SA rekey which is carried out with a specific message sequence. This will eventually result in an iked process crash and restart.
The iked process memory consumption can be checked using the below command:
user@host> show system processes extensive | grep iked
PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND
56903 root 31 0 4016M 2543M CPU0 0 2:10 10.50% iked
This issue affects Juniper Networks Junos OS:
* All versions earlier than 20.4R3-S9;
* 21.2 versions earlier than 21.2R3-S7;
* 21.3 versions earlier than 21.3R3-S5;
* 21.4 versions earlier than 21.4R3-S4;
* 22.1 versions earlier than 22.1R3-S3;
* 22.2 versions earlier than 22.2R3-S2;
* 22.3 versions earlier than 22.3R3;
* 22.4 versions earlier than 22.4R3;
* 23.2 versions earlier than 23.2R1-S2, 23.2R2.
| CVSS 6.5 | Juniper | - | - |  |
CVE-2024-21599
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 adjacent, unauthenticated attacker to cause a Denial of Service (DoS).
If an MX Series device receives PTP packets on an MPC3E that doesn't support PTP this causes a memory leak which will result in unpredictable behavior and ultimately in an MPC crash and restart.
To monitor for this issue, please use the following FPC vty level commands:
show heap
shows an increase in "LAN buffer" utilization and
show clksync ptp nbr-upd-info
shows non-zero "Pending PFEs" counter.
This issue affects Juniper Networks Junos OS on MX Series with MPC3E:
* All versions earlier than 20.4R3-S3;
* 21.1 versions earlier than 21.1R3-S4;
* 21.2 versions earlier than 21.2R3;
* 21.3 versions earlier than 21.3R2-S1, 21.3R3;
* 21.4 versions earlier than 21.4R2;
* 22.1 versions earlier than 22.1R2.
| CVSS 6.5 | Juniper | - | Patched |  |
CVE-2024-20304A vulnerability in the multicast traceroute version 2 (Mtrace2) feature of Cisco IOS XR Software could allow an unauthenticated, remote attacker to exhaust the UDP packet memory of an affected device.
This vulnerability exists because the Mtrace2 code does not properly handle packet memory. An attacker could exploit this vulnerability by sending crafted packets to an affected device. A successful exploit could allow the attacker to exhaust the incoming UDP packet memory. The affected device would not be able to process higher-level UDP-based protocols packets, possibly causing a denial of service (DoS) condition.
Note: This vulnerability can be exploited using IPv4 or IPv6. | CVSS 7.5 | Cisco | - | Patched |  |
CVE-2024-1394A memory leak flaw was found in Golang in the RSA encrypting/decrypting code, which might lead to a resource exhaustion vulnerability using attacker-controlled inputs. The memory leak happens in github.com/golang-fips/openssl/openssl/rsa.go#L113. The objects leaked are pkey and ctx. That function uses named return parameters to free pkey and ctx if there is an error initializing the context or setting the different properties. All return statements related to error cases follow the "return nil, nil, fail(...)" pattern, meaning that pkey and ctx will be nil inside the deferred function that should free them. | CVSS 7.5 | Golang | - | Patched |  |
CVE-2024-0395A vulnerability has been identified in cptutils, where a malicious user could trigger a Denial of Service (DoS) by exploiting a memory leak during the internal processing of certificates. | CVSS 3.9 | - | Patched |  | |
CVE-2024-0240A memory leak in the Silicon Labs' Bluetooth stack for EFR32 products may cause memory to be exhausted when sending notifications to multiple clients, this results in all Bluetooth operations, such as advertising and scanning, to stop. | CVSS 6.5 | - | - |  | |
CVE-2024-0058A flaw was found in .NET where a malicious user could cause Denial of Service (DoS) due to internal processing of certificates memory leak. | CVSS 7.5 | - | Patched |  | |
CVE-2023-7192A memory leak problem was found in ctnetlink_create_conntrack in net/netfilter/nf_conntrack_netlink.c in the Linux Kernel. This issue may allow a local attacker with CAP_NET_ADMIN privileges to cause a denial of service (DoS) attack due to a refcount overflow. | CVSS 4.4 | Linux, et al | - | Patched |  |
CVE-2023-6299A vulnerability, which was classified as problematic, has been found in Apryse iText 8.0.2. This issue affects some unknown processing of the file PdfDocument.java of the component Reference Table Handler. The manipulation leads to memory leak. The attack may be initiated remotely. The exploit has been disclosed to the public and may be used. The identifier VDB-246125 was assigned to this vulnerability. NOTE: The vendor was contacted early about this disclosure but did not respond in any way. | CVSS 6.5 | Itextpdf | - | - |  |
CVE-2023-6180The tokio-boring library in version 4.0.0 is affected by a memory leak issue that can lead to excessive resource consumption and potential DoS by resource exhaustion. The set_ex_data function used by the library did not deallocate memory used by pre-existing data in memory each time after completing a TLS connection causing the program to consume more resources with each new connection.
| CVSS 5.3 | Cloudflare | - | Patched |  |