| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix possible memory leak in btrfs_get_dev_args_from_path()
In btrfs_get_dev_args_from_path(), btrfs_get_bdev_and_sb() can fail if
the path is invalid. In this case, btrfs_get_dev_args_from_path()
returns directly without freeing args->uuid and args->fsid allocated
before, which causes memory leak.
To fix these possible leaks, when btrfs_get_bdev_and_sb() fails,
btrfs_put_dev_args_from_path() is called to clean up the memory. |
| In the Linux kernel, the following vulnerability has been resolved:
net: lantiq_xrx200: restore buffer if memory allocation failed
In a situation where memory allocation fails, an invalid buffer address
is stored. When this descriptor is used again, the system panics in the
build_skb() function when accessing memory. |
| In the Linux kernel, the following vulnerability has been resolved:
openvswitch: fix memory leak at failed datapath creation
ovs_dp_cmd_new()->ovs_dp_change()->ovs_dp_set_upcall_portids()
allocates array via kmalloc.
If for some reason new_vport() fails during ovs_dp_cmd_new()
dp->upcall_portids must be freed.
Add missing kfree.
Kmemleak example:
unreferenced object 0xffff88800c382500 (size 64):
comm "dump_state", pid 323, jiffies 4294955418 (age 104.347s)
hex dump (first 32 bytes):
5e c2 79 e4 1f 7a 38 c7 09 21 38 0c 80 88 ff ff ^.y..z8..!8.....
03 00 00 00 0a 00 00 00 14 00 00 00 28 00 00 00 ............(...
backtrace:
[<0000000071bebc9f>] ovs_dp_set_upcall_portids+0x38/0xa0
[<000000000187d8bd>] ovs_dp_change+0x63/0xe0
[<000000002397e446>] ovs_dp_cmd_new+0x1f0/0x380
[<00000000aa06f36e>] genl_family_rcv_msg_doit+0xea/0x150
[<000000008f583bc4>] genl_rcv_msg+0xdc/0x1e0
[<00000000fa10e377>] netlink_rcv_skb+0x50/0x100
[<000000004959cece>] genl_rcv+0x24/0x40
[<000000004699ac7f>] netlink_unicast+0x23e/0x360
[<00000000c153573e>] netlink_sendmsg+0x24e/0x4b0
[<000000006f4aa380>] sock_sendmsg+0x62/0x70
[<00000000d0068654>] ____sys_sendmsg+0x230/0x270
[<0000000012dacf7d>] ___sys_sendmsg+0x88/0xd0
[<0000000011776020>] __sys_sendmsg+0x59/0xa0
[<000000002e8f2dc1>] do_syscall_64+0x3b/0x90
[<000000003243e7cb>] entry_SYSCALL_64_after_hwframe+0x63/0xcd |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amd/pm: add missing ->fini_xxxx interfaces for some SMU13 asics
Without these, potential memory leak may be induced. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amd/pm: add missing ->fini_microcode interface for Sienna Cichlid
To avoid any potential memory leak. |
| In the Linux kernel, the following vulnerability has been resolved:
virtio-net: free xsk_buffs on error in virtnet_xsk_pool_enable()
The selftests added to our CI by Bui Quang Minh recently reveals
that there is a mem leak on the error path of virtnet_xsk_pool_enable():
unreferenced object 0xffff88800a68a000 (size 2048):
comm "xdp_helper", pid 318, jiffies 4294692778
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):
__kvmalloc_node_noprof+0x402/0x570
virtnet_xsk_pool_enable+0x293/0x6a0 (drivers/net/virtio_net.c:5882)
xp_assign_dev+0x369/0x670 (net/xdp/xsk_buff_pool.c:226)
xsk_bind+0x6a5/0x1ae0
__sys_bind+0x15e/0x230
__x64_sys_bind+0x72/0xb0
do_syscall_64+0xc1/0x1d0
entry_SYSCALL_64_after_hwframe+0x77/0x7f |
| In the Linux kernel, the following vulnerability has been resolved:
block: fix resource leak in blk_register_queue() error path
When registering a queue fails after blk_mq_sysfs_register() is
successful but the function later encounters an error, we need
to clean up the blk_mq_sysfs resources.
Add the missing blk_mq_sysfs_unregister() call in the error path
to properly clean up these resources and prevent a memory leak. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amd/pm: Fix a potential gpu_metrics_table memory leak
Memory is allocated for gpu_metrics_table in
smu_v13_0_4_init_smc_tables(), but not freed in
smu_v13_0_4_fini_smc_tables(). This may cause memory leaks, fix it. |
| In the Linux kernel, the following vulnerability has been resolved:
scsi: lpfc: Fix possible memory leak when failing to issue CMF WQE
There is no corresponding free routine if lpfc_sli4_issue_wqe fails to
issue the CMF WQE in lpfc_issue_cmf_sync_wqe.
If ret_val is non-zero, then free the iocbq request structure. |
| In the Linux kernel, the following vulnerability has been resolved:
cxl: Fix a memory leak in an error handling path
A bitmap_zalloc() must be balanced by a corresponding bitmap_free() in the
error handling path of afu_allocate_irqs(). |
| In the Linux kernel, the following vulnerability has been resolved:
net: genl: fix error path memory leak in policy dumping
If construction of the array of policies fails when recording
non-first policy we need to unwind.
netlink_policy_dump_add_policy() itself also needs fixing as
it currently gives up on error without recording the allocated
pointer in the pstate pointer. |
| In the Linux kernel, the following vulnerability has been resolved:
net/sunrpc: fix potential memory leaks in rpc_sysfs_xprt_state_change()
The issue happens on some error handling paths. When the function
fails to grab the object `xprt`, it simply returns 0, forgetting to
decrease the reference count of another object `xps`, which is
increased by rpc_sysfs_xprt_kobj_get_xprt_switch(), causing refcount
leaks. Also, the function forgets to check whether `xps` is valid
before using it, which may result in NULL-dereferencing issues.
Fix it by adding proper error handling code when either `xprt` or
`xps` is NULL. |
| In the Linux kernel, the following vulnerability has been resolved:
octeontx2-af: Fix mcam entry resource leak
The teardown sequence in FLR handler returns if no NIX LF
is attached to PF/VF because it indicates that graceful
shutdown of resources already happened. But there is a
chance of all allocated MCAM entries not being freed by
PF/VF. Hence free mcam entries even in case of detached LF. |
| In the Linux kernel, the following vulnerability has been resolved:
interconnect: exynos: fix node leak in probe PM QoS error path
Make sure to add the newly allocated interconnect node to the provider
before adding the PM QoS request so that the node is freed on errors. |
| In the Linux kernel, the following vulnerability has been resolved:
interconnect: fix mem leak when freeing nodes
The node link array is allocated when adding links to a node but is not
deallocated when nodes are destroyed. |
| In the Linux kernel, the following vulnerability has been resolved:
net: usb: lan78xx: Limit packet length to skb->len
Packet length retrieved from descriptor may be larger than
the actual socket buffer length. In such case the cloned
skb passed up the network stack will leak kernel memory contents.
Additionally prevent integer underflow when size is less than
ETH_FCS_LEN. |
| In the Linux kernel, the following vulnerability has been resolved:
octeontx2-vf: Add missing free for alloc_percpu
Add the free_percpu for the allocated "vf->hw.lmt_info" in order to avoid
memory leak, same as the "pf->hw.lmt_info" in
`drivers/net/ethernet/marvell/octeontx2/nic/otx2_pf.c`. |
| In the Linux kernel, the following vulnerability has been resolved:
scsi: scsi_dh_alua: Fix memleak for 'qdata' in alua_activate()
If alua_rtpg_queue() failed from alua_activate(), then 'qdata' is not
freed, which will cause following memleak:
unreferenced object 0xffff88810b2c6980 (size 32):
comm "kworker/u16:2", pid 635322, jiffies 4355801099 (age 1216426.076s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
40 39 24 c1 ff ff ff ff 00 f8 ea 0a 81 88 ff ff @9$.............
backtrace:
[<0000000098f3a26d>] alua_activate+0xb0/0x320
[<000000003b529641>] scsi_dh_activate+0xb2/0x140
[<000000007b296db3>] activate_path_work+0xc6/0xe0 [dm_multipath]
[<000000007adc9ace>] process_one_work+0x3c5/0x730
[<00000000c457a985>] worker_thread+0x93/0x650
[<00000000cb80e628>] kthread+0x1ba/0x210
[<00000000a1e61077>] ret_from_fork+0x22/0x30
Fix the problem by freeing 'qdata' in error path. |
| In the Linux kernel, the following vulnerability has been resolved:
net: ngbe: fix memory leak in ngbe_probe() error path
When ngbe_sw_init() is called, memory is allocated for wx->rss_key
in wx_init_rss_key(). However, in ngbe_probe() function, the subsequent
error paths after ngbe_sw_init() don't free the rss_key. Fix that by
freeing it in error path along with wx->mac_table.
Also change the label to which execution jumps when ngbe_sw_init()
fails, because otherwise, it could lead to a double free for rss_key,
when the mac_table allocation fails in wx_sw_init(). |
| In the Linux kernel, the following vulnerability has been resolved:
net: txgbe: fix memory leak in txgbe_probe() error path
When txgbe_sw_init() is called, memory is allocated for wx->rss_key
in wx_init_rss_key(). However, in txgbe_probe() function, the subsequent
error paths after txgbe_sw_init() don't free the rss_key. Fix that by
freeing it in error path along with wx->mac_table.
Also change the label to which execution jumps when txgbe_sw_init()
fails, because otherwise, it could lead to a double free for rss_key,
when the mac_table allocation fails in wx_sw_init(). |
