| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
coresight: Fix memory leak in acpi_buffer->pointer
There are memory leaks reported by kmemleak:
...
unreferenced object 0xffff00213c141000 (size 1024):
comm "systemd-udevd", pid 2123, jiffies 4294909467 (age 6062.160s)
hex dump (first 32 bytes):
04 00 00 00 02 00 00 00 18 10 14 3c 21 00 ff ff ...........<!...
00 00 00 00 00 00 00 00 03 00 00 00 10 00 00 00 ................
backtrace:
[<000000004b7c9001>] __kmem_cache_alloc_node+0x2f8/0x348
[<00000000b0fc7ceb>] __kmalloc+0x58/0x108
[<0000000064ff4695>] acpi_os_allocate+0x2c/0x68
[<000000007d57d116>] acpi_ut_initialize_buffer+0x54/0xe0
[<0000000024583908>] acpi_evaluate_object+0x388/0x438
[<0000000017b2e72b>] acpi_evaluate_object_typed+0xe8/0x240
[<000000005df0eac2>] coresight_get_platform_data+0x1b4/0x988 [coresight]
...
The ACPI buffer memory (buf.pointer) should be freed. But the buffer
is also used after returning from acpi_get_dsd_graph().
Move the temporary variables buf to acpi_coresight_parse_graph(),
and free it before the function return to prevent memory leak. |
| In the Linux kernel, the following vulnerability has been resolved:
staging: greybus: audio_helper: remove unused and wrong debugfs usage
In the greybus audio_helper code, the debugfs file for the dapm has the
potential to be removed and memory will be leaked. There is also the
very real potential for this code to remove ALL debugfs entries from the
system, and it seems like this is what will really happen if this code
ever runs. This all is very wrong as the greybus audio driver did not
create this debugfs file, the sound core did and controls the lifespan
of it.
So remove all of the debugfs logic from the audio_helper code as there's
no way it could be correct. If this really is needed, it can come back
with a fixup for the incorrect usage of the debugfs_lookup() call which
is what caused this to be noticed at all. |
| In the Linux kernel, the following vulnerability has been resolved:
net: sched: fix memory leak in tcindex_set_parms
Syzkaller reports a memory leak as follows:
====================================
BUG: memory leak
unreferenced object 0xffff88810c287f00 (size 256):
comm "syz-executor105", pid 3600, jiffies 4294943292 (age 12.990s)
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:
[<ffffffff814cf9f0>] kmalloc_trace+0x20/0x90 mm/slab_common.c:1046
[<ffffffff839c9e07>] kmalloc include/linux/slab.h:576 [inline]
[<ffffffff839c9e07>] kmalloc_array include/linux/slab.h:627 [inline]
[<ffffffff839c9e07>] kcalloc include/linux/slab.h:659 [inline]
[<ffffffff839c9e07>] tcf_exts_init include/net/pkt_cls.h:250 [inline]
[<ffffffff839c9e07>] tcindex_set_parms+0xa7/0xbe0 net/sched/cls_tcindex.c:342
[<ffffffff839caa1f>] tcindex_change+0xdf/0x120 net/sched/cls_tcindex.c:553
[<ffffffff8394db62>] tc_new_tfilter+0x4f2/0x1100 net/sched/cls_api.c:2147
[<ffffffff8389e91c>] rtnetlink_rcv_msg+0x4dc/0x5d0 net/core/rtnetlink.c:6082
[<ffffffff839eba67>] netlink_rcv_skb+0x87/0x1d0 net/netlink/af_netlink.c:2540
[<ffffffff839eab87>] netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]
[<ffffffff839eab87>] netlink_unicast+0x397/0x4c0 net/netlink/af_netlink.c:1345
[<ffffffff839eb046>] netlink_sendmsg+0x396/0x710 net/netlink/af_netlink.c:1921
[<ffffffff8383e796>] sock_sendmsg_nosec net/socket.c:714 [inline]
[<ffffffff8383e796>] sock_sendmsg+0x56/0x80 net/socket.c:734
[<ffffffff8383eb08>] ____sys_sendmsg+0x178/0x410 net/socket.c:2482
[<ffffffff83843678>] ___sys_sendmsg+0xa8/0x110 net/socket.c:2536
[<ffffffff838439c5>] __sys_sendmmsg+0x105/0x330 net/socket.c:2622
[<ffffffff83843c14>] __do_sys_sendmmsg net/socket.c:2651 [inline]
[<ffffffff83843c14>] __se_sys_sendmmsg net/socket.c:2648 [inline]
[<ffffffff83843c14>] __x64_sys_sendmmsg+0x24/0x30 net/socket.c:2648
[<ffffffff84605fd5>] do_syscall_x64 arch/x86/entry/common.c:50 [inline]
[<ffffffff84605fd5>] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
[<ffffffff84800087>] entry_SYSCALL_64_after_hwframe+0x63/0xcd
====================================
Kernel uses tcindex_change() to change an existing
filter properties.
Yet the problem is that, during the process of changing,
if `old_r` is retrieved from `p->perfect`, then
kernel uses tcindex_alloc_perfect_hash() to newly
allocate filter results, uses tcindex_filter_result_init()
to clear the old filter result, without destroying
its tcf_exts structure, which triggers the above memory leak.
To be more specific, there are only two source for the `old_r`,
according to the tcindex_lookup(). `old_r` is retrieved from
`p->perfect`, or `old_r` is retrieved from `p->h`.
* If `old_r` is retrieved from `p->perfect`, kernel uses
tcindex_alloc_perfect_hash() to newly allocate the
filter results. Then `r` is assigned with `cp->perfect + handle`,
which is newly allocated. So condition `old_r && old_r != r` is
true in this situation, and kernel uses tcindex_filter_result_init()
to clear the old filter result, without destroying
its tcf_exts structure
* If `old_r` is retrieved from `p->h`, then `p->perfect` is NULL
according to the tcindex_lookup(). Considering that `cp->h`
is directly copied from `p->h` and `p->perfect` is NULL,
`r` is assigned with `tcindex_lookup(cp, handle)`, whose value
should be the same as `old_r`, so condition `old_r && old_r != r`
is false in this situation, kernel ignores using
tcindex_filter_result_init() to clear the old filter result.
So only when `old_r` is retrieved from `p->perfect` does kernel use
tcindex_filter_result_init() to clear the old filter result, which
triggers the above memory leak.
Considering that there already exists a tc_filter_wq workqueue
to destroy the old tcindex_d
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
integrity: Fix memory leakage in keyring allocation error path
Key restriction is allocated in integrity_init_keyring(). However, if
keyring allocation failed, it is not freed, causing memory leaks. |
| In the Linux kernel, the following vulnerability has been resolved:
mm/mempolicy: fix memory leak in set_mempolicy_home_node system call
When encountering any vma in the range with policy other than MPOL_BIND or
MPOL_PREFERRED_MANY, an error is returned without issuing a mpol_put on
the policy just allocated with mpol_dup().
This allows arbitrary users to leak kernel memory. |
| In the Linux kernel, the following vulnerability has been resolved:
tpm: tpm_crb: Add the missed acpi_put_table() to fix memory leak
In crb_acpi_add(), we get the TPM2 table to retrieve information
like start method, and then assign them to the priv data, so the
TPM2 table is not used after the init, should be freed, call
acpi_put_table() to fix the memory leak. |
| In the Linux kernel, the following vulnerability has been resolved:
net: hinic: fix the issue of CMDQ memory leaks
When hinic_set_cmdq_depth() fails in hinic_init_cmdqs(), the cmdq memory is
not released correctly. Fix it. |
| In the Linux kernel, the following vulnerability has been resolved:
orangefs: Fix kmemleak in orangefs_{kernel,client}_debug_init()
When insert and remove the orangefs module, there are memory leaked
as below:
unreferenced object 0xffff88816b0cc000 (size 2048):
comm "insmod", pid 783, jiffies 4294813439 (age 65.512s)
hex dump (first 32 bytes):
6e 6f 6e 65 0a 00 00 00 00 00 00 00 00 00 00 00 none............
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<0000000031ab7788>] kmalloc_trace+0x27/0xa0
[<000000005b405fee>] orangefs_debugfs_init.cold+0xaf/0x17f
[<00000000e5a0085b>] 0xffffffffa02780f9
[<000000004232d9f7>] do_one_initcall+0x87/0x2a0
[<0000000054f22384>] do_init_module+0xdf/0x320
[<000000003263bdea>] load_module+0x2f98/0x3330
[<0000000052cd4153>] __do_sys_finit_module+0x113/0x1b0
[<00000000250ae02b>] do_syscall_64+0x35/0x80
[<00000000f11c03c7>] entry_SYSCALL_64_after_hwframe+0x46/0xb0
Use the golbal variable as the buffer rather than dynamic allocate to
slove the problem. |
| 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:
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. |
| 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:
net: hns: fix possible memory leak in hnae_ae_register()
Inject fault while probing module, if device_register() fails,
but the refcount of kobject is not decreased to 0, the name
allocated in dev_set_name() is leaked. Fix this by calling
put_device(), so that name can be freed in callback function
kobject_cleanup().
unreferenced object 0xffff00c01aba2100 (size 128):
comm "systemd-udevd", pid 1259, jiffies 4294903284 (age 294.152s)
hex dump (first 32 bytes):
68 6e 61 65 30 00 00 00 18 21 ba 1a c0 00 ff ff hnae0....!......
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<0000000034783f26>] slab_post_alloc_hook+0xa0/0x3e0
[<00000000748188f2>] __kmem_cache_alloc_node+0x164/0x2b0
[<00000000ab0743e8>] __kmalloc_node_track_caller+0x6c/0x390
[<000000006c0ffb13>] kvasprintf+0x8c/0x118
[<00000000fa27bfe1>] kvasprintf_const+0x60/0xc8
[<0000000083e10ed7>] kobject_set_name_vargs+0x3c/0xc0
[<000000000b87affc>] dev_set_name+0x7c/0xa0
[<000000003fd8fe26>] hnae_ae_register+0xcc/0x190 [hnae]
[<00000000fe97edc9>] hns_dsaf_ae_init+0x9c/0x108 [hns_dsaf]
[<00000000c36ff1eb>] hns_dsaf_probe+0x548/0x748 [hns_dsaf] |
| In the Linux kernel, the following vulnerability has been resolved:
cifs: Fix xid leak in cifs_create()
If the cifs already shutdown, we should free the xid before return,
otherwise, the xid will be leaked. |
| In the Linux kernel, the following vulnerability has been resolved:
misc: tifm: fix possible memory leak in tifm_7xx1_switch_media()
If device_register() returns error in tifm_7xx1_switch_media(),
name of kobject which is allocated in dev_set_name() called in device_add()
is leaked.
Never directly free @dev after calling device_register(), even
if it returned an error! Always use put_device() to give up the
reference initialized. |
| In the Linux kernel, the following vulnerability has been resolved:
nfsd: Fix a memory leak in an error handling path
If this memdup_user() call fails, the memory allocated in a previous call
a few lines above should be freed. Otherwise it leaks. |
| In the Linux kernel, the following vulnerability has been resolved:
rapidio: fix possible name leaks when rio_add_device() fails
Patch series "rapidio: fix three possible memory leaks".
This patchset fixes three name leaks in error handling.
- patch #1 fixes two name leaks while rio_add_device() fails.
- patch #2 fixes a name leak while rio_register_mport() fails.
This patch (of 2):
If rio_add_device() returns error, the name allocated by dev_set_name()
need be freed. It should use put_device() to give up the reference in the
error path, so that the name can be freed in kobject_cleanup(), and the
'rdev' can be freed in rio_release_dev(). |
| In the Linux kernel, the following vulnerability has been resolved:
floppy: Fix memory leak in do_floppy_init()
A memory leak was reported when floppy_alloc_disk() failed in
do_floppy_init().
unreferenced object 0xffff888115ed25a0 (size 8):
comm "modprobe", pid 727, jiffies 4295051278 (age 25.529s)
hex dump (first 8 bytes):
00 ac 67 5b 81 88 ff ff ..g[....
backtrace:
[<000000007f457abb>] __kmalloc_node+0x4c/0xc0
[<00000000a87bfa9e>] blk_mq_realloc_tag_set_tags.part.0+0x6f/0x180
[<000000006f02e8b1>] blk_mq_alloc_tag_set+0x573/0x1130
[<0000000066007fd7>] 0xffffffffc06b8b08
[<0000000081f5ac40>] do_one_initcall+0xd0/0x4f0
[<00000000e26d04ee>] do_init_module+0x1a4/0x680
[<000000001bb22407>] load_module+0x6249/0x7110
[<00000000ad31ac4d>] __do_sys_finit_module+0x140/0x200
[<000000007bddca46>] do_syscall_64+0x35/0x80
[<00000000b5afec39>] entry_SYSCALL_64_after_hwframe+0x46/0xb0
unreferenced object 0xffff88810fc30540 (size 32):
comm "modprobe", pid 727, jiffies 4295051278 (age 25.529s)
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:
[<000000007f457abb>] __kmalloc_node+0x4c/0xc0
[<000000006b91eab4>] blk_mq_alloc_tag_set+0x393/0x1130
[<0000000066007fd7>] 0xffffffffc06b8b08
[<0000000081f5ac40>] do_one_initcall+0xd0/0x4f0
[<00000000e26d04ee>] do_init_module+0x1a4/0x680
[<000000001bb22407>] load_module+0x6249/0x7110
[<00000000ad31ac4d>] __do_sys_finit_module+0x140/0x200
[<000000007bddca46>] do_syscall_64+0x35/0x80
[<00000000b5afec39>] entry_SYSCALL_64_after_hwframe+0x46/0xb0
If the floppy_alloc_disk() failed, disks of current drive will not be set,
thus the lastest allocated set->tag cannot be freed in the error handling
path. A simple call graph shown as below:
floppy_module_init()
floppy_init()
do_floppy_init()
for (drive = 0; drive < N_DRIVE; drive++)
blk_mq_alloc_tag_set()
blk_mq_alloc_tag_set_tags()
blk_mq_realloc_tag_set_tags() # set->tag allocated
floppy_alloc_disk()
blk_mq_alloc_disk() # error occurred, disks failed to allocated
->out_put_disk:
for (drive = 0; drive < N_DRIVE; drive++)
if (!disks[drive][0]) # the last disks is not set and loop break
break;
blk_mq_free_tag_set() # the latest allocated set->tag leaked
Fix this problem by free the set->tag of current drive before jump to
error handling path.
[efremov: added stable list, changed title] |
| A vulnerability in the Internet Key Exchange Version 2 (IKEv2) module of Cisco IOS Software and Cisco IOS XE Software could allow an unauthenticated, remote attacker to cause a memory leak or a reload of an affected device that leads to a denial of service (DoS) condition. The vulnerability is due to incorrect processing of certain IKEv2 packets. An attacker could exploit this vulnerability by sending crafted IKEv2 packets to an affected device to be processed. A successful exploit could cause an affected device to continuously consume memory and eventually reload, resulting in a DoS condition. Cisco Bug IDs: CSCvf22394. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: ath12k: fix memory leak in ath12k_service_ready_ext_event
Currently, in ath12k_service_ready_ext_event(), svc_rdy_ext.mac_phy_caps
is not freed in the failure case, causing a memory leak. The following
trace is observed in kmemleak:
unreferenced object 0xffff8b3eb5789c00 (size 1024):
comm "softirq", pid 0, jiffies 4294942577
hex dump (first 32 bytes):
00 00 00 00 01 00 00 00 00 00 00 00 7b 00 00 10 ............{...
01 00 00 00 00 00 00 00 01 00 00 00 1f 38 00 00 .............8..
backtrace (crc 44e1c357):
__kmalloc_noprof+0x30b/0x410
ath12k_wmi_mac_phy_caps_parse+0x84/0x100 [ath12k]
ath12k_wmi_tlv_iter+0x5e/0x140 [ath12k]
ath12k_wmi_svc_rdy_ext_parse+0x308/0x4c0 [ath12k]
ath12k_wmi_tlv_iter+0x5e/0x140 [ath12k]
ath12k_service_ready_ext_event.isra.0+0x44/0xd0 [ath12k]
ath12k_wmi_op_rx+0x2eb/0xd70 [ath12k]
ath12k_htc_rx_completion_handler+0x1f4/0x330 [ath12k]
ath12k_ce_recv_process_cb+0x218/0x300 [ath12k]
ath12k_pci_ce_workqueue+0x1b/0x30 [ath12k]
process_one_work+0x219/0x680
bh_worker+0x198/0x1f0
tasklet_action+0x13/0x30
handle_softirqs+0xca/0x460
__irq_exit_rcu+0xbe/0x110
irq_exit_rcu+0x9/0x30
Free svc_rdy_ext.mac_phy_caps in the error case to fix this memory leak.
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 |
| In the Linux kernel, the following vulnerability has been resolved:
firmware: stratix10-svc: Fix a potential resource leak in svc_create_memory_pool()
svc_create_memory_pool() is only called from stratix10_svc_drv_probe().
Most of resources in the probe are managed, but not this memremap() call.
There is also no memunmap() call in the file.
So switch to devm_memremap() to avoid a resource leak. |
