| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
scsi: snic: Fix possible memory leak if device_add() fails
If device_add() returns error, the name allocated by dev_set_name() needs
be freed. As the comment of device_add() says, put_device() should be used
to give up the reference in the error path. So fix this by calling
put_device(), then the name can be freed in kobject_cleanp(). |
| In the Linux kernel, the following vulnerability has been resolved:
cifs: Fix memory leak when build ntlmssp negotiate blob failed
There is a memory leak when mount cifs:
unreferenced object 0xffff888166059600 (size 448):
comm "mount.cifs", pid 51391, jiffies 4295596373 (age 330.596s)
hex dump (first 32 bytes):
fe 53 4d 42 40 00 00 00 00 00 00 00 01 00 82 00 .SMB@...........
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<0000000060609a61>] mempool_alloc+0xe1/0x260
[<00000000adfa6c63>] cifs_small_buf_get+0x24/0x60
[<00000000ebb404c7>] __smb2_plain_req_init+0x32/0x460
[<00000000bcf875b4>] SMB2_sess_alloc_buffer+0xa4/0x3f0
[<00000000753a2987>] SMB2_sess_auth_rawntlmssp_negotiate+0xf5/0x480
[<00000000f0c1f4f9>] SMB2_sess_setup+0x253/0x410
[<00000000a8b83303>] cifs_setup_session+0x18f/0x4c0
[<00000000854bd16d>] cifs_get_smb_ses+0xae7/0x13c0
[<000000006cbc43d9>] mount_get_conns+0x7a/0x730
[<000000005922d816>] cifs_mount+0x103/0xd10
[<00000000e33def3b>] cifs_smb3_do_mount+0x1dd/0xc90
[<0000000078034979>] smb3_get_tree+0x1d5/0x300
[<000000004371f980>] vfs_get_tree+0x41/0xf0
[<00000000b670d8a7>] path_mount+0x9b3/0xdd0
[<000000005e839a7d>] __x64_sys_mount+0x190/0x1d0
[<000000009404c3b9>] do_syscall_64+0x35/0x80
When build ntlmssp negotiate blob failed, the session setup request
should be freed. |
| In the Linux kernel, the following vulnerability has been resolved:
cassini: Fix a memory leak in the error handling path of cas_init_one()
cas_saturn_firmware_init() allocates some memory using vmalloc(). This
memory is freed in the .remove() function but not it the error handling
path of the probe.
Add the missing vfree() to avoid a memory leak, should an error occur. |
| In the Linux kernel, the following vulnerability has been resolved:
net/tcp: Fix socket memory leak in TCP-AO failure handling for IPv6
When tcp_ao_copy_all_matching() fails in tcp_v6_syn_recv_sock() it just
exits the function. This ends up causing a memory-leak:
unreferenced object 0xffff0000281a8200 (size 2496):
comm "softirq", pid 0, jiffies 4295174684
hex dump (first 32 bytes):
7f 00 00 06 7f 00 00 06 00 00 00 00 cb a8 88 13 ................
0a 00 03 61 00 00 00 00 00 00 00 00 00 00 00 00 ...a............
backtrace (crc 5ebdbe15):
kmemleak_alloc+0x44/0xe0
kmem_cache_alloc_noprof+0x248/0x470
sk_prot_alloc+0x48/0x120
sk_clone_lock+0x38/0x3b0
inet_csk_clone_lock+0x34/0x150
tcp_create_openreq_child+0x3c/0x4a8
tcp_v6_syn_recv_sock+0x1c0/0x620
tcp_check_req+0x588/0x790
tcp_v6_rcv+0x5d0/0xc18
ip6_protocol_deliver_rcu+0x2d8/0x4c0
ip6_input_finish+0x74/0x148
ip6_input+0x50/0x118
ip6_sublist_rcv+0x2fc/0x3b0
ipv6_list_rcv+0x114/0x170
__netif_receive_skb_list_core+0x16c/0x200
netif_receive_skb_list_internal+0x1f0/0x2d0
This is because in tcp_v6_syn_recv_sock (and the IPv4 counterpart), when
exiting upon error, inet_csk_prepare_forced_close() and tcp_done() need
to be called. They make sure the newsk will end up being correctly
free'd.
tcp_v4_syn_recv_sock() makes this very clear by having the put_and_exit
label that takes care of things. So, this patch here makes sure
tcp_v4_syn_recv_sock and tcp_v6_syn_recv_sock have similar
error-handling and thus fixes the leak for TCP-AO. |
| In the Linux kernel, the following vulnerability has been resolved:
bpf: cpumap: Fix memory leak in cpu_map_update_elem
Syzkaller reported a memory leak as follows:
BUG: memory leak
unreferenced object 0xff110001198ef748 (size 192):
comm "syz-executor.3", pid 17672, jiffies 4298118891 (age 9.906s)
hex dump (first 32 bytes):
00 00 00 00 4a 19 00 00 80 ad e3 e4 fe ff c0 00 ....J...........
00 b2 d3 0c 01 00 11 ff 28 f5 8e 19 01 00 11 ff ........(.......
backtrace:
[<ffffffffadd28087>] __cpu_map_entry_alloc+0xf7/0xb00
[<ffffffffadd28d8e>] cpu_map_update_elem+0x2fe/0x3d0
[<ffffffffadc6d0fd>] bpf_map_update_value.isra.0+0x2bd/0x520
[<ffffffffadc7349b>] map_update_elem+0x4cb/0x720
[<ffffffffadc7d983>] __se_sys_bpf+0x8c3/0xb90
[<ffffffffb029cc80>] do_syscall_64+0x30/0x40
[<ffffffffb0400099>] entry_SYSCALL_64_after_hwframe+0x61/0xc6
BUG: memory leak
unreferenced object 0xff110001198ef528 (size 192):
comm "syz-executor.3", pid 17672, jiffies 4298118891 (age 9.906s)
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:
[<ffffffffadd281f0>] __cpu_map_entry_alloc+0x260/0xb00
[<ffffffffadd28d8e>] cpu_map_update_elem+0x2fe/0x3d0
[<ffffffffadc6d0fd>] bpf_map_update_value.isra.0+0x2bd/0x520
[<ffffffffadc7349b>] map_update_elem+0x4cb/0x720
[<ffffffffadc7d983>] __se_sys_bpf+0x8c3/0xb90
[<ffffffffb029cc80>] do_syscall_64+0x30/0x40
[<ffffffffb0400099>] entry_SYSCALL_64_after_hwframe+0x61/0xc6
BUG: memory leak
unreferenced object 0xff1100010fd93d68 (size 8):
comm "syz-executor.3", pid 17672, jiffies 4298118891 (age 9.906s)
hex dump (first 8 bytes):
00 00 00 00 00 00 00 00 ........
backtrace:
[<ffffffffade5db3e>] kvmalloc_node+0x11e/0x170
[<ffffffffadd28280>] __cpu_map_entry_alloc+0x2f0/0xb00
[<ffffffffadd28d8e>] cpu_map_update_elem+0x2fe/0x3d0
[<ffffffffadc6d0fd>] bpf_map_update_value.isra.0+0x2bd/0x520
[<ffffffffadc7349b>] map_update_elem+0x4cb/0x720
[<ffffffffadc7d983>] __se_sys_bpf+0x8c3/0xb90
[<ffffffffb029cc80>] do_syscall_64+0x30/0x40
[<ffffffffb0400099>] entry_SYSCALL_64_after_hwframe+0x61/0xc6
In the cpu_map_update_elem flow, when kthread_stop is called before
calling the threadfn of rcpu->kthread, since the KTHREAD_SHOULD_STOP bit
of kthread has been set by kthread_stop, the threadfn of rcpu->kthread
will never be executed, and rcpu->refcnt will never be 0, which will
lead to the allocated rcpu, rcpu->queue and rcpu->queue->queue cannot be
released.
Calling kthread_stop before executing kthread's threadfn will return
-EINTR. We can complete the release of memory resources in this state. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: dma: fix memory leak running mt76_dma_tx_cleanup
Fix device unregister memory leak and alway cleanup all configured
rx queues in mt76_dma_tx_cleanup routine. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: iwlwifi: fw: fix memory leak in debugfs
Fix a memory leak that occurs when reading the fw_info
file all the way, since we return NULL indicating no
more data, but don't free the status tracking object. |
| In the Linux kernel, the following vulnerability has been resolved:
fbdev: fbcon: release buffer when fbcon_do_set_font() failed
syzbot is reporting memory leak at fbcon_do_set_font() [1], for
commit a5a923038d70 ("fbdev: fbcon: Properly revert changes when
vc_resize() failed") missed that the buffer might be newly allocated
by fbcon_set_font(). |
| In the Linux kernel, the following vulnerability has been resolved:
PM: EM: fix memory leak with using debugfs_lookup()
When calling debugfs_lookup() the result must have dput() called on it,
otherwise the memory will leak over time. To make things simpler, just
call debugfs_lookup_and_remove() instead which handles all of the logic
at once. |
| In the Linux kernel, the following vulnerability has been resolved:
clk: mediatek: fix of_iomap memory leak
Smatch reports:
drivers/clk/mediatek/clk-mtk.c:583 mtk_clk_simple_probe() warn:
'base' from of_iomap() not released on lines: 496.
This problem was also found in linux-next. In mtk_clk_simple_probe(),
base is not released when handling errors
if clk_data is not existed, which may cause a leak.
So free_base should be added here to release base. |
| In the Linux kernel, the following vulnerability has been resolved:
objtool: Fix memory leak in create_static_call_sections()
strdup() allocates memory for key_name. We need to release the memory in
the following error paths. Add free() to avoid memory leak. |
| In the Linux kernel, the following vulnerability has been resolved:
media: ov2740: Fix memleak in ov2740_init_controls()
There is a kmemleak when testing the media/i2c/ov2740.c with bpf mock
device:
unreferenced object 0xffff8881090e19e0 (size 16):
comm "51-i2c-ov2740", pid 278, jiffies 4294781584 (age 23.613s)
hex dump (first 16 bytes):
00 f3 7c 0b 81 88 ff ff 80 75 6a 09 81 88 ff ff ..|......uj.....
backtrace:
[<000000004e9fad8f>] __kmalloc_node+0x44/0x1b0
[<0000000039c802f4>] kvmalloc_node+0x34/0x180
[<000000009b8b5c63>] v4l2_ctrl_handler_init_class+0x11d/0x180
[videodev]
[<0000000038644056>] ov2740_probe+0x37d/0x84f [ov2740]
[<0000000092489f59>] i2c_device_probe+0x28d/0x680
[<000000001038babe>] really_probe+0x17c/0x3f0
[<0000000098c7af1c>] __driver_probe_device+0xe3/0x170
[<00000000e1b3dc24>] device_driver_attach+0x34/0x80
[<000000005a04a34d>] bind_store+0x10b/0x1a0
[<00000000ce25d4f2>] drv_attr_store+0x49/0x70
[<000000007d9f4e9a>] sysfs_kf_write+0x8c/0xb0
[<00000000be6cff0f>] kernfs_fop_write_iter+0x216/0x2e0
[<0000000031ddb40a>] vfs_write+0x658/0x810
[<0000000041beecdd>] ksys_write+0xd6/0x1b0
[<0000000023755840>] do_syscall_64+0x38/0x90
[<00000000b2cc2da2>] entry_SYSCALL_64_after_hwframe+0x63/0xcd
ov2740_init_controls() won't clean all the allocated resources in fail
path, which may causes the memleaks. Add v4l2_ctrl_handler_free() to
prevent memleak. |
| In the Linux kernel, the following vulnerability has been resolved:
accel/qaic: Fix slicing memory leak
The temporary buffer storing slicing configuration data from user is only
freed on error. This is a memory leak. Free the buffer unconditionally. |
| In the Linux kernel, the following vulnerability has been resolved:
accel/habanalabs: postpone mem_mgr IDR destruction to hpriv_release()
The memory manager IDR is currently destroyed when user releases the
file descriptor.
However, at this point the user context might be still held, and memory
buffers might be still in use.
Later on, calls to release those buffers will fail due to not finding
their handles in the IDR, leading to a memory leak.
To avoid this leak, split the IDR destruction from the memory manager
fini, and postpone it to hpriv_release() when there is no user context
and no buffers are used. |
| In the Linux kernel, the following vulnerability has been resolved:
staging: pi433: fix memory leak with using debugfs_lookup()
When calling debugfs_lookup() the result must have dput() called on it,
otherwise the memory will leak over time. To make things simpler, just
call debugfs_lookup_and_remove() instead which handles all of the logic
at once. This requires saving off the root directory dentry to make
creation of individual device subdirectories easier. |
| In the Linux kernel, the following vulnerability has been resolved:
caif: fix memory leak in cfctrl_linkup_request()
When linktype is unknown or kzalloc failed in cfctrl_linkup_request(),
pkt is not released. Add release process to error path. |
| When 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. |
| In the Linux kernel, the following vulnerability has been resolved:
staging: vt6655: fix some erroneous memory clean-up loops
In some initialization functions of this driver, memory is allocated with
'i' acting as an index variable and increasing from 0. The commit in
"Fixes" introduces some clean-up codes in case of allocation failure,
which free memory in reverse order with 'i' decreasing to 0. However,
there are some problems:
- The case i=0 is left out. Thus memory is leaked.
- In case memory allocation fails right from the start, the memory
freeing loops will start with i=-1 and invalid memory locations will
be accessed.
One of these loops has been fixed in commit c8ff91535880 ("staging:
vt6655: fix potential memory leak"). Fix the remaining erroneous loops. |
| In the Linux kernel, the following vulnerability has been resolved:
ptp: ocp: Fix a resource leak in an error handling path
If an error occurs after a successful 'pci_ioremap_bar()' call, it must be
undone by a corresponding 'pci_iounmap()' call, as already done in the
remove function. |
| In the Linux kernel, the following vulnerability has been resolved:
usb: dwc3: core: fix some leaks in probe
The dwc3_get_properties() function calls:
dwc->usb_psy = power_supply_get_by_name(usb_psy_name);
so there is some additional clean up required on these error paths. |
