| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| A 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. |
| A flaw was found in libssh's handling of key exchange (KEX) processes when a client repeatedly sends incorrect KEX guesses. The library fails to free memory during these rekey operations, which can gradually exhaust system memory. This issue can lead to crashes on the client side, particularly when using libgcrypt, which impacts application stability and availability. |
| In the Linux kernel, the following vulnerability has been resolved:
xsk: Free skb when TX metadata options are invalid
When a new skb is allocated for transmitting an xsk descriptor, i.e., for
every non-multibuf descriptor or the first frag of a multibuf descriptor,
but the descriptor is later found to have invalid options set for the TX
metadata, the new skb is never freed. This can leak skbs until the send
buffer is full which makes sending more packets impossible.
Fix this by freeing the skb in the error path if we are currently dealing
with the first frag, i.e., an skb allocated in this iteration of
xsk_build_skb. |
| In the Linux kernel, the following vulnerability has been resolved:
vsock: Fix sk_error_queue memory leak
Kernel queues MSG_ZEROCOPY completion notifications on the error queue.
Where they remain, until explicitly recv()ed. To prevent memory leaks,
clean up the queue when the socket is destroyed.
unreferenced object 0xffff8881028beb00 (size 224):
comm "vsock_test", pid 1218, jiffies 4294694897
hex dump (first 32 bytes):
90 b0 21 17 81 88 ff ff 90 b0 21 17 81 88 ff ff ..!.......!.....
00 00 00 00 00 00 00 00 00 b0 21 17 81 88 ff ff ..........!.....
backtrace (crc 6c7031ca):
[<ffffffff81418ef7>] kmem_cache_alloc_node_noprof+0x2f7/0x370
[<ffffffff81d35882>] __alloc_skb+0x132/0x180
[<ffffffff81d2d32b>] sock_omalloc+0x4b/0x80
[<ffffffff81d3a8ae>] msg_zerocopy_realloc+0x9e/0x240
[<ffffffff81fe5cb2>] virtio_transport_send_pkt_info+0x412/0x4c0
[<ffffffff81fe6183>] virtio_transport_stream_enqueue+0x43/0x50
[<ffffffff81fe0813>] vsock_connectible_sendmsg+0x373/0x450
[<ffffffff81d233d5>] ____sys_sendmsg+0x365/0x3a0
[<ffffffff81d246f4>] ___sys_sendmsg+0x84/0xd0
[<ffffffff81d26f47>] __sys_sendmsg+0x47/0x80
[<ffffffff820d3df3>] do_syscall_64+0x93/0x180
[<ffffffff8220012b>] entry_SYSCALL_64_after_hwframe+0x76/0x7e |
| In the Linux kernel, the following vulnerability has been resolved:
virtio/vsock: Improve MSG_ZEROCOPY error handling
Add a missing kfree_skb() to prevent memory leaks. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/xe: Fix possible exec queue leak in exec IOCTL
In a couple of places after an exec queue is looked up the exec IOCTL
returns on input errors without dropping the exec queue ref. Fix this
ensuring the exec queue ref is dropped on input error.
(cherry picked from commit 07064a200b40ac2195cb6b7b779897d9377e5e6f) |
| In the Linux kernel, the following vulnerability has been resolved:
drm/imagination: Break an object reference loop
When remaining resources are being cleaned up on driver close,
outstanding VM mappings may result in resources being leaked, due
to an object reference loop, as shown below, with each object (or
set of objects) referencing the object below it:
PVR GEM Object
GPU scheduler "finished" fence
GPU scheduler “scheduled” fence
PVR driver “done” fence
PVR Context
PVR VM Context
PVR VM Mappings
PVR GEM Object
The reference that the PVR VM Context has on the VM mappings is a
soft one, in the sense that the freeing of outstanding VM mappings
is done as part of VM context destruction; no reference counts are
involved, as is the case for all the other references in the loop.
To break the reference loop during cleanup, free the outstanding
VM mappings before destroying the PVR Context associated with the
VM context. |
| In the Linux kernel, the following vulnerability has been resolved:
rpcrdma: Always release the rpcrdma_device's xa_array
Dai pointed out that the xa_init_flags() in rpcrdma_add_one() needs
to have a matching xa_destroy() in rpcrdma_remove_one() to release
underlying memory that the xarray might have accrued during
operation. |
| In the Linux kernel, the following vulnerability has been resolved:
iio: gts-helper: Fix memory leaks for the error path of iio_gts_build_avail_scale_table()
If per_time_scales[i] or per_time_gains[i] kcalloc fails in the for loop
of iio_gts_build_avail_scale_table(), the err_free_out will fail to call
kfree() each time when i is reduced to 0, so all the per_time_scales[0]
and per_time_gains[0] will not be freed, which will cause memory leaks.
Fix it by checking if i >= 0. |
| In 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. |
| In 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(). |
| In 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. |
| In 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. |
| In the Linux kernel, the following vulnerability has been resolved:
pinctrl: intel: platform: fix error path in device_for_each_child_node()
The device_for_each_child_node() loop requires calls to
fwnode_handle_put() upon early returns to decrement the refcount of
the child node and avoid leaking memory if that error path is triggered.
There is one early returns within that loop in
intel_platform_pinctrl_prepare_community(), but fwnode_handle_put() is
missing.
Instead of adding the missing call, the scoped version of the loop can
be used to simplify the code and avoid mistakes in the future if new
early returns are added, as the child node is only used for parsing, and
it is never assigned. |
| In the Linux kernel, the following vulnerability has been resolved:
ice: fix memleak in ice_init_tx_topology()
Fix leak of the FW blob (DDP pkg).
Make ice_cfg_tx_topo() const-correct, so ice_init_tx_topology() can avoid
copying whole FW blob. Copy just the topology section, and only when
needed. Reuse the buffer allocated for the read of the current topology.
This was found by kmemleak, with the following trace for each PF:
[<ffffffff8761044d>] kmemdup_noprof+0x1d/0x50
[<ffffffffc0a0a480>] ice_init_ddp_config+0x100/0x220 [ice]
[<ffffffffc0a0da7f>] ice_init_dev+0x6f/0x200 [ice]
[<ffffffffc0a0dc49>] ice_init+0x29/0x560 [ice]
[<ffffffffc0a10c1d>] ice_probe+0x21d/0x310 [ice]
Constify ice_cfg_tx_topo() @buf parameter.
This cascades further down to few more functions. |
| In 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". |
| In 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. |
| In the Linux kernel, the following vulnerability has been resolved:
fsl/fman: Fix refcount handling of fman-related devices
In mac_probe() there are multiple calls to of_find_device_by_node(),
fman_bind() and fman_port_bind() which takes references to of_dev->dev.
Not all references taken by these calls are released later on error path
in mac_probe() and in mac_remove() which lead to reference leaks.
Add references release. |
| In the Linux kernel, the following vulnerability has been resolved:
bpf: Preserve param->string when parsing mount options
In bpf_parse_param(), keep the value of param->string intact so it can
be freed later. Otherwise, the kmalloc area pointed to by param->string
will be leaked as shown below:
unreferenced object 0xffff888118c46d20 (size 8):
comm "new_name", pid 12109, jiffies 4295580214
hex dump (first 8 bytes):
61 6e 79 00 38 c9 5c 7e any.8.\~
backtrace (crc e1b7f876):
[<00000000c6848ac7>] kmemleak_alloc+0x4b/0x80
[<00000000de9f7d00>] __kmalloc_node_track_caller_noprof+0x36e/0x4a0
[<000000003e29b886>] memdup_user+0x32/0xa0
[<0000000007248326>] strndup_user+0x46/0x60
[<0000000035b3dd29>] __x64_sys_fsconfig+0x368/0x3d0
[<0000000018657927>] x64_sys_call+0xff/0x9f0
[<00000000c0cabc95>] do_syscall_64+0x3b/0xc0
[<000000002f331597>] entry_SYSCALL_64_after_hwframe+0x4b/0x53 |
| In 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 |
