| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
jffs2: fix memory leak in jffs2_do_fill_super
If jffs2_iget() or d_make_root() in jffs2_do_fill_super() returns
an error, we can observe the following kmemleak report:
--------------------------------------------
unreferenced object 0xffff888105a65340 (size 64):
comm "mount", pid 710, jiffies 4302851558 (age 58.239s)
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:
[<ffffffff859c45e5>] kmem_cache_alloc_trace+0x475/0x8a0
[<ffffffff86160146>] jffs2_sum_init+0x96/0x1a0
[<ffffffff86140e25>] jffs2_do_mount_fs+0x745/0x2120
[<ffffffff86149fec>] jffs2_do_fill_super+0x35c/0x810
[<ffffffff8614aae9>] jffs2_fill_super+0x2b9/0x3b0
[...]
unreferenced object 0xffff8881bd7f0000 (size 65536):
comm "mount", pid 710, jiffies 4302851558 (age 58.239s)
hex dump (first 32 bytes):
bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb ................
bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb ................
backtrace:
[<ffffffff858579ba>] kmalloc_order+0xda/0x110
[<ffffffff85857a11>] kmalloc_order_trace+0x21/0x130
[<ffffffff859c2ed1>] __kmalloc+0x711/0x8a0
[<ffffffff86160189>] jffs2_sum_init+0xd9/0x1a0
[<ffffffff86140e25>] jffs2_do_mount_fs+0x745/0x2120
[<ffffffff86149fec>] jffs2_do_fill_super+0x35c/0x810
[<ffffffff8614aae9>] jffs2_fill_super+0x2b9/0x3b0
[...]
--------------------------------------------
This is because the resources allocated in jffs2_sum_init() are not
released. Call jffs2_sum_exit() to release these resources to solve
the problem. |
| In the Linux kernel, the following vulnerability has been resolved:
firmware: dmi-sysfs: Fix memory leak in dmi_sysfs_register_handle
kobject_init_and_add() takes reference even when it fails.
According to the doc of kobject_init_and_add()
If this function returns an error, kobject_put() must be called to
properly clean up the memory associated with the object.
Fix this issue by calling kobject_put(). |
| In the Linux kernel, the following vulnerability has been resolved:
amt: fix possible memory leak in amt_rcv()
If an amt receives packets and it finds socket.
If it can't find a socket, it should free a received skb.
But it doesn't.
So, a memory leak would possibly occur. |
| In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix reference count leak in smb_check_perm_dacl()
The issue happens in a specific path in smb_check_perm_dacl(). When
"id" and "uid" have the same value, the function simply jumps out of
the loop without decrementing the reference count of the object
"posix_acls", which is increased by get_acl() earlier. This may
result in memory leaks.
Fix it by decreasing the reference count of "posix_acls" before
jumping to label "check_access_bits". |
| In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: memleak flow rule from commit path
Abort path release flow rule object, however, commit path does not.
Update code to destroy these objects before releasing the transaction. |
| In the Linux kernel, the following vulnerability has been resolved:
mm/huge_memory: Fix xarray node memory leak
If xas_split_alloc() fails to allocate the necessary nodes to complete the
xarray entry split, it sets the xa_state to -ENOMEM, which xas_nomem()
then interprets as "Please allocate more memory", not as "Please free
any unnecessary memory" (which was the intended outcome). It's confusing
to use xas_nomem() to free memory in this context, so call xas_destroy()
instead. |
| In the Linux kernel, the following vulnerability has been resolved:
nfc: st21nfca: fix memory leaks in EVT_TRANSACTION handling
Error paths do not free previously allocated memory. Add devm_kfree() to
those failure paths. |
| In the Linux kernel, the following vulnerability has been resolved:
tty: Fix a possible resource leak in icom_probe
When pci_read_config_dword failed, call pci_release_regions() and
pci_disable_device() to recycle the resource previously allocated. |
| In the Linux kernel, the following vulnerability has been resolved:
staging: rtl8712: fix a potential memory leak in r871xu_drv_init()
In r871xu_drv_init(), if r8712_init_drv_sw() fails, then the memory
allocated by r8712_alloc_io_queue() in r8712_usb_dvobj_init() is not
properly released as there is no action will be performed by
r8712_usb_dvobj_deinit().
To properly release it, we should call r8712_free_io_queue() in
r8712_usb_dvobj_deinit().
Besides, in r871xu_dev_remove(), r8712_usb_dvobj_deinit() will be called
by r871x_dev_unload() under condition `padapter->bup` and
r8712_free_io_queue() is called by r8712_free_drv_sw().
However, r8712_usb_dvobj_deinit() does not rely on `padapter->bup` and
calling r8712_free_io_queue() in r8712_free_drv_sw() is negative for
better understading the code.
So I move r8712_usb_dvobj_deinit() into r871xu_dev_remove(), and remove
r8712_free_io_queue() from r8712_free_drv_sw(). |
| In the Linux kernel, the following vulnerability has been resolved:
coresight: syscfg: Fix memleak on registration failure in cscfg_create_device
device_register() calls device_initialize(),
according to doc of device_initialize:
Use put_device() to give up your reference instead of freeing
* @dev directly once you have called this function.
To prevent potential memleak, use put_device() for error handling. |
| In the Linux kernel, the following vulnerability has been resolved:
jffs2: fix memory leak in jffs2_do_mount_fs
If jffs2_build_filesystem() in jffs2_do_mount_fs() returns an error,
we can observe the following kmemleak report:
--------------------------------------------
unreferenced object 0xffff88811b25a640 (size 64):
comm "mount", pid 691, jiffies 4294957728 (age 71.952s)
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:
[<ffffffffa493be24>] kmem_cache_alloc_trace+0x584/0x880
[<ffffffffa5423a06>] jffs2_sum_init+0x86/0x130
[<ffffffffa5400e58>] jffs2_do_mount_fs+0x798/0xac0
[<ffffffffa540acf3>] jffs2_do_fill_super+0x383/0xc30
[<ffffffffa540c00a>] jffs2_fill_super+0x2ea/0x4c0
[...]
unreferenced object 0xffff88812c760000 (size 65536):
comm "mount", pid 691, jiffies 4294957728 (age 71.952s)
hex dump (first 32 bytes):
bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb ................
bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb ................
backtrace:
[<ffffffffa493a449>] __kmalloc+0x6b9/0x910
[<ffffffffa5423a57>] jffs2_sum_init+0xd7/0x130
[<ffffffffa5400e58>] jffs2_do_mount_fs+0x798/0xac0
[<ffffffffa540acf3>] jffs2_do_fill_super+0x383/0xc30
[<ffffffffa540c00a>] jffs2_fill_super+0x2ea/0x4c0
[...]
--------------------------------------------
This is because the resources allocated in jffs2_sum_init() are not
released. Call jffs2_sum_exit() to release these resources to solve
the problem. |
| In the Linux kernel, the following vulnerability has been resolved:
jffs2: fix memory leak in jffs2_scan_medium
If an error is returned in jffs2_scan_eraseblock() and some memory
has been added to the jffs2_summary *s, we can observe the following
kmemleak report:
--------------------------------------------
unreferenced object 0xffff88812b889c40 (size 64):
comm "mount", pid 692, jiffies 4294838325 (age 34.288s)
hex dump (first 32 bytes):
40 48 b5 14 81 88 ff ff 01 e0 31 00 00 00 50 00 @H........1...P.
00 00 01 00 00 00 01 00 00 00 02 00 00 00 09 08 ................
backtrace:
[<ffffffffae93a3a3>] __kmalloc+0x613/0x910
[<ffffffffaf423b9c>] jffs2_sum_add_dirent_mem+0x5c/0xa0
[<ffffffffb0f3afa8>] jffs2_scan_medium.cold+0x36e5/0x4794
[<ffffffffb0f3dbe1>] jffs2_do_mount_fs.cold+0xa7/0x2267
[<ffffffffaf40acf3>] jffs2_do_fill_super+0x383/0xc30
[<ffffffffaf40c00a>] jffs2_fill_super+0x2ea/0x4c0
[<ffffffffb0315d64>] mtd_get_sb+0x254/0x400
[<ffffffffb0315f5f>] mtd_get_sb_by_nr+0x4f/0xd0
[<ffffffffb0316478>] get_tree_mtd+0x498/0x840
[<ffffffffaf40bd15>] jffs2_get_tree+0x25/0x30
[<ffffffffae9f358d>] vfs_get_tree+0x8d/0x2e0
[<ffffffffaea7a98f>] path_mount+0x50f/0x1e50
[<ffffffffaea7c3d7>] do_mount+0x107/0x130
[<ffffffffaea7c5c5>] __se_sys_mount+0x1c5/0x2f0
[<ffffffffaea7c917>] __x64_sys_mount+0xc7/0x160
[<ffffffffb10142f5>] do_syscall_64+0x45/0x70
unreferenced object 0xffff888114b54840 (size 32):
comm "mount", pid 692, jiffies 4294838325 (age 34.288s)
hex dump (first 32 bytes):
c0 75 b5 14 81 88 ff ff 02 e0 02 00 00 00 02 00 .u..............
00 00 84 00 00 00 44 00 00 00 6b 6b 6b 6b 6b a5 ......D...kkkkk.
backtrace:
[<ffffffffae93be24>] kmem_cache_alloc_trace+0x584/0x880
[<ffffffffaf423b04>] jffs2_sum_add_inode_mem+0x54/0x90
[<ffffffffb0f3bd44>] jffs2_scan_medium.cold+0x4481/0x4794
[...]
unreferenced object 0xffff888114b57280 (size 32):
comm "mount", pid 692, jiffies 4294838393 (age 34.357s)
hex dump (first 32 bytes):
10 d5 6c 11 81 88 ff ff 08 e0 05 00 00 00 01 00 ..l.............
00 00 38 02 00 00 28 00 00 00 6b 6b 6b 6b 6b a5 ..8...(...kkkkk.
backtrace:
[<ffffffffae93be24>] kmem_cache_alloc_trace+0x584/0x880
[<ffffffffaf423c34>] jffs2_sum_add_xattr_mem+0x54/0x90
[<ffffffffb0f3a24f>] jffs2_scan_medium.cold+0x298c/0x4794
[...]
unreferenced object 0xffff8881116cd510 (size 16):
comm "mount", pid 692, jiffies 4294838395 (age 34.355s)
hex dump (first 16 bytes):
00 00 00 00 00 00 00 00 09 e0 60 02 00 00 6b a5 ..........`...k.
backtrace:
[<ffffffffae93be24>] kmem_cache_alloc_trace+0x584/0x880
[<ffffffffaf423cc4>] jffs2_sum_add_xref_mem+0x54/0x90
[<ffffffffb0f3b2e3>] jffs2_scan_medium.cold+0x3a20/0x4794
[...]
--------------------------------------------
Therefore, we should call jffs2_sum_reset_collected(s) on exit to
release the memory added in s. In addition, a new tag "out_buf" is
added to prevent the NULL pointer reference caused by s being NULL.
(thanks to Zhang Yi for this analysis) |
| In the Linux kernel, the following vulnerability has been resolved:
ASoC: mxs: Fix error handling in mxs_sgtl5000_probe
This function only calls of_node_put() in the regular path.
And it will cause refcount leak in error paths.
For example, when codec_np is NULL, saif_np[0] and saif_np[1]
are not NULL, it will cause leaks.
of_node_put() will check if the node pointer is NULL, so we can
call it directly to release the refcount of regular pointers. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Call dc_stream_release for remove link enc assignment
[Why]
A porting error resulted in the stream assignment for the link
being retained without being released - a memory leak.
[How]
Fix the porting error by adding back the dc_stream_release() intended
as part of the original patch. |
| In the Linux kernel, the following vulnerability has been resolved:
rtw88: fix memory overrun and memory leak during hw_scan
Previously we allocated less memory than actual required, overwrite
to the buffer causes the mm module to complaint and raise access
violation faults. Along with potential memory leaks when returned
early. Fix these by passing the correct size and proper deinit flow. |
| In the Linux kernel, the following vulnerability has been resolved:
mt76: mt7915: fix possible memory leak in mt7915_mcu_add_sta
Free allocated skb in mt7915_mcu_add_sta routine in case of failures. |
| In the Linux kernel, the following vulnerability has been resolved:
mt76: mt7921s: fix a possible memory leak in mt7921_load_patch
Always release fw data at the end of mt7921_load_patch routine. |
| In the Linux kernel, the following vulnerability has been resolved:
power: supply: ab8500: Fix memory leak in ab8500_fg_sysfs_init
kobject_init_and_add() takes reference even when it fails.
According to the doc of kobject_init_and_add():
If this function returns an error, kobject_put() must be called to
properly clean up the memory associated with the object.
Fix memory leak by calling kobject_put(). |
| In the Linux kernel, the following vulnerability has been resolved:
MIPS: pgalloc: fix memory leak caused by pgd_free()
pgd page is freed by generic implementation pgd_free() since commit
f9cb654cb550 ("asm-generic: pgalloc: provide generic pgd_free()"),
however, there are scenarios that the system uses more than one page as
the pgd table, in such cases the generic implementation pgd_free() won't
be applicable anymore. For example, when PAGE_SIZE_4KB is enabled and
MIPS_VA_BITS_48 is not enabled in a 64bit system, the macro "PGD_ORDER"
will be set as "1", which will cause allocating two pages as the pgd
table. Well, at the same time, the generic implementation pgd_free()
just free one pgd page, which will result in the memory leak.
The memory leak can be easily detected by executing shell command:
"while true; do ls > /dev/null; grep MemFree /proc/meminfo; done" |
| In the Linux kernel, the following vulnerability has been resolved:
bpf, sockmap: Fix memleak in tcp_bpf_sendmsg while sk msg is full
If tcp_bpf_sendmsg() is running while sk msg is full. When sk_msg_alloc()
returns -ENOMEM error, tcp_bpf_sendmsg() goes to wait_for_memory. If partial
memory has been alloced by sk_msg_alloc(), that is, msg_tx->sg.size is
greater than osize after sk_msg_alloc(), memleak occurs. To fix we use
sk_msg_trim() to release the allocated memory, then goto wait for memory.
Other call paths of sk_msg_alloc() have the similar issue, such as
tls_sw_sendmsg(), so handle sk_msg_trim logic inside sk_msg_alloc(),
as Cong Wang suggested.
This issue can cause the following info:
WARNING: CPU: 3 PID: 7950 at net/core/stream.c:208 sk_stream_kill_queues+0xd4/0x1a0
Call Trace:
<TASK>
inet_csk_destroy_sock+0x55/0x110
__tcp_close+0x279/0x470
tcp_close+0x1f/0x60
inet_release+0x3f/0x80
__sock_release+0x3d/0xb0
sock_close+0x11/0x20
__fput+0x92/0x250
task_work_run+0x6a/0xa0
do_exit+0x33b/0xb60
do_group_exit+0x2f/0xa0
get_signal+0xb6/0x950
arch_do_signal_or_restart+0xac/0x2a0
exit_to_user_mode_prepare+0xa9/0x200
syscall_exit_to_user_mode+0x12/0x30
do_syscall_64+0x46/0x80
entry_SYSCALL_64_after_hwframe+0x44/0xae
</TASK>
WARNING: CPU: 3 PID: 2094 at net/ipv4/af_inet.c:155 inet_sock_destruct+0x13c/0x260
Call Trace:
<TASK>
__sk_destruct+0x24/0x1f0
sk_psock_destroy+0x19b/0x1c0
process_one_work+0x1b3/0x3c0
kthread+0xe6/0x110
ret_from_fork+0x22/0x30
</TASK> |