| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
ice: fix eswitch code memory leak in reset scenario
Add simple eswitch mode checker in attaching VF procedure and allocate
required port representor memory structures only in switchdev mode.
The reset flows triggers VF (if present) detach/attach procedure.
It might involve VF port representor(s) re-creation if the device is
configured is switchdev mode (not legacy one).
The memory was blindly allocated in current implementation,
regardless of the mode and not freed if in legacy mode.
Kmemeleak trace:
unreferenced object (percpu) 0x7e3bce5b888458 (size 40):
comm "bash", pid 1784, jiffies 4295743894
hex dump (first 32 bytes on cpu 45):
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):
pcpu_alloc_noprof+0x4c4/0x7c0
ice_repr_create+0x66/0x130 [ice]
ice_repr_create_vf+0x22/0x70 [ice]
ice_eswitch_attach_vf+0x1b/0xa0 [ice]
ice_reset_all_vfs+0x1dd/0x2f0 [ice]
ice_pci_err_resume+0x3b/0xb0 [ice]
pci_reset_function+0x8f/0x120
reset_store+0x56/0xa0
kernfs_fop_write_iter+0x120/0x1b0
vfs_write+0x31c/0x430
ksys_write+0x61/0xd0
do_syscall_64+0x5b/0x180
entry_SYSCALL_64_after_hwframe+0x76/0x7e
Testing hints (ethX is PF netdev):
- create at least one VF
echo 1 > /sys/class/net/ethX/device/sriov_numvfs
- trigger the reset
echo 1 > /sys/class/net/ethX/device/reset |
| In the Linux kernel, the following vulnerability has been resolved:
nvmet: fix memory leak of bio integrity
If nvmet receives commands with metadata there is a continuous memory
leak of kmalloc-128 slab or more precisely bio->bi_integrity.
Since commit bf4c89fc8797 ("block: don't call bio_uninit from bio_endio")
each user of bio_init has to use bio_uninit as well. Otherwise the bio
integrity is not getting free. Nvmet uses bio_init for inline bios.
Uninit the inline bio to complete deallocation of integrity in bio. |
| In the Linux kernel, the following vulnerability has been resolved:
ASoC: SOF: Intel: hda: Use devm_kstrdup() to avoid memleak.
sof_pdata->tplg_filename can have address allocated by kstrdup()
and can be overwritten. Memory leak was detected with kmemleak:
unreferenced object 0xffff88812391ff60 (size 16):
comm "kworker/4:1", pid 161, jiffies 4294802931
hex dump (first 16 bytes):
73 6f 66 2d 68 64 61 2d 67 65 6e 65 72 69 63 00 sof-hda-generic.
backtrace (crc 4bf1675c):
__kmalloc_node_track_caller_noprof+0x49c/0x6b0
kstrdup+0x46/0xc0
hda_machine_select.cold+0x1de/0x12cf [snd_sof_intel_hda_generic]
sof_init_environment+0x16f/0xb50 [snd_sof]
sof_probe_continue+0x45/0x7c0 [snd_sof]
sof_probe_work+0x1e/0x40 [snd_sof]
process_one_work+0x894/0x14b0
worker_thread+0x5e5/0xfb0
kthread+0x39d/0x760
ret_from_fork+0x31/0x70
ret_from_fork_asm+0x1a/0x30 |
| In the Linux kernel, the following vulnerability has been resolved:
crypto: ccp - Use kzalloc for sev ioctl interfaces to prevent kernel memory leak
For some sev ioctl interfaces, input may be passed that is less than or
equal to SEV_FW_BLOB_MAX_SIZE, but larger than the data that PSP
firmware returns. In this case, kmalloc will allocate memory that is the
size of the input rather than the size of the data. Since PSP firmware
doesn't fully overwrite the buffer, the sev ioctl interfaces with the
issue may return uninitialized slab memory.
Currently, all of the ioctl interfaces in the ccp driver are safe, but
to prevent future problems, change all ioctl interfaces that allocate
memory with kmalloc to use kzalloc and memset the data buffer to zero
in sev_ioctl_do_platform_status. |
| In the Linux kernel, the following vulnerability has been resolved:
ath11k: fix missing skb drop on htc_tx_completion error
On htc_tx_completion error the skb is not dropped. This is wrong since
the completion_handler logic expect the skb to be consumed anyway even
when an error is triggered. Not freeing the skb on error is a memory
leak since the skb won't be freed anywere else. Correctly free the
packet on eid >= ATH11K_HTC_EP_COUNT before returning.
Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.5.0.1-01208-QCAHKSWPL_SILICONZ-1 |
| In the Linux kernel, the following vulnerability has been resolved:
selinux: fix memleak in security_read_state_kernel()
In this function, it directly returns the result of __security_read_policy
without freeing the allocated memory in *data, cause memory leak issue,
so free the memory if __security_read_policy failed.
[PM: subject line tweak] |
| In the Linux kernel, the following vulnerability has been resolved:
efivarfs: Fix memory leak of efivarfs_fs_info in fs_context error paths
When processing mount options, efivarfs allocates efivarfs_fs_info (sfi)
early in fs_context initialization. However, sfi is associated with the
superblock and typically freed when the superblock is destroyed. If the
fs_context is released (final put) before fill_super is called—such as
on error paths or during reconfiguration—the sfi structure would leak,
as ownership never transfers to the superblock.
Implement the .free callback in efivarfs_context_ops to ensure any
allocated sfi is properly freed if the fs_context is torn down before
fill_super, preventing this memory leak. |
| In the Linux kernel, the following vulnerability has been resolved:
net: ethernet: ti: am65-cpsw-nuss: Fix skb size by accounting for skb_shared_info
While transitioning from netdev_alloc_ip_align() to build_skb(), memory
for the "skb_shared_info" member of an "skb" was not allocated. Fix this
by allocating "PAGE_SIZE" as the skb length, accounting for the packet
length, headroom and tailroom, thereby including the required memory space
for skb_shared_info. |
| In the Linux kernel, the following vulnerability has been resolved:
RDMA/hfi1: fix potential memory leak in setup_base_ctxt()
setup_base_ctxt() allocates a memory chunk for uctxt->groups with
hfi1_alloc_ctxt_rcv_groups(). When init_user_ctxt() fails, uctxt->groups
is not released, which will lead to a memory leak.
We should release the uctxt->groups with hfi1_free_ctxt_rcv_groups()
when init_user_ctxt() fails. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: ath12k: Fix memory leak due to multiple rx_stats allocation
rx_stats for each arsta is allocated when adding a station.
arsta->rx_stats will be freed when a station is removed.
Redundant allocations are occurring when the same station is added
multiple times. This causes ath12k_mac_station_add() to be called
multiple times, and rx_stats is allocated each time. As a result there
is memory leaks.
Prevent multiple allocations of rx_stats when ath12k_mac_station_add()
is called repeatedly by checking if rx_stats is already allocated
before allocating again. Allocate arsta->rx_stats if arsta->rx_stats
is NULL respectively.
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1
Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 |
| In the Linux kernel, the following vulnerability has been resolved:
media: imagination: fix a potential memory leak in e5010_probe()
Add video_device_release() to release the memory allocated by
video_device_alloc() if something goes wrong. |
| A flaw was found in libsoup. It is vulnerable to memory leaks in the soup_header_parse_quality_list() function when parsing a quality list that contains elements with all zeroes. |
| In the Linux kernel, the following vulnerability has been resolved:
RDMA/qedr: Fix potential memory leak in __qedr_alloc_mr()
__qedr_alloc_mr() allocates a memory chunk for "mr->info.pbl_table" with
init_mr_info(). When rdma_alloc_tid() and rdma_register_tid() fail, "mr"
is released while "mr->info.pbl_table" is not released, which will lead
to a memory leak.
We should release the "mr->info.pbl_table" with qedr_free_pbl() when error
occurs to fix the memory leak. |
| In the Linux kernel, the following vulnerability has been resolved:
memstick/ms_block: Fix a memory leak
'erased_blocks_bitmap' is never freed. As it is allocated at the same time
as 'used_blocks_bitmap', it is likely that it should be freed also at the
same time.
Add the corresponding bitmap_free() in msb_data_clear(). |
| In the Linux kernel, the following vulnerability has been resolved:
mm/damon/reclaim: fix potential memory leak in damon_reclaim_init()
damon_reclaim_init() allocates a memory chunk for ctx with
damon_new_ctx(). When damon_select_ops() fails, ctx is not released,
which will lead to a memory leak.
We should release the ctx with damon_destroy_ctx() when damon_select_ops()
fails to fix the memory leak. |
| In the Linux kernel, the following vulnerability has been resolved:
PCI: dwc: Deallocate EPC memory on dw_pcie_ep_init() errors
If dw_pcie_ep_init() fails to perform any action after the EPC memory is
initialized and the MSI memory region is allocated, the latter parts won't
be undone thus causing a memory leak. Add a cleanup-on-error path to fix
these leaks.
[bhelgaas: commit log] |
| In the Linux kernel, the following vulnerability has been resolved:
watchdog: sp5100_tco: Fix a memory leak of EFCH MMIO resource
Unlike release_mem_region(), a call to release_resource() does not
free the resource, so it has to be freed explicitly to avoid a memory
leak. |
| In the Linux kernel, the following vulnerability has been resolved:
cifs: Fix memory leak when using fscache
If we hit the 'index == next_cached' case, we leak a refcount on the
struct page. Fix this by using readahead_folio() which takes care of
the refcount for you. |
| In the Linux kernel, the following vulnerability has been resolved:
apparmor: Fix memleak in aa_simple_write_to_buffer()
When copy_from_user failed, the memory is freed by kvfree. however the
management struct and data blob are allocated independently, so only
kvfree(data) cause a memleak issue here. Use aa_put_loaddata(data) to
fix this issue. |
| In the Linux kernel, the following vulnerability has been resolved:
cifs: Fix memory leak on the deferred close
xfstests on smb21 report kmemleak as below:
unreferenced object 0xffff8881767d6200 (size 64):
comm "xfs_io", pid 1284, jiffies 4294777434 (age 20.789s)
hex dump (first 32 bytes):
80 5a d0 11 81 88 ff ff 78 8a aa 63 81 88 ff ff .Z......x..c....
00 71 99 76 81 88 ff ff 00 00 00 00 00 00 00 00 .q.v............
backtrace:
[<00000000ad04e6ea>] cifs_close+0x92/0x2c0
[<0000000028b93c82>] __fput+0xff/0x3f0
[<00000000d8116851>] task_work_run+0x85/0xc0
[<0000000027e14f9e>] do_exit+0x5e5/0x1240
[<00000000fb492b95>] do_group_exit+0x58/0xe0
[<00000000129a32d9>] __x64_sys_exit_group+0x28/0x30
[<00000000e3f7d8e9>] do_syscall_64+0x35/0x80
[<00000000102e8a0b>] entry_SYSCALL_64_after_hwframe+0x46/0xb0
When cancel the deferred close work, we should also cleanup the struct
cifs_deferred_close. |
