| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| xmlParseBalancedChunkMemoryRecover in parser.c in libxml2 before 2.9.10 has a memory leak related to newDoc->oldNs. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/vkms: Fix memory leak in vkms_init()
A memory leak was reported after the vkms module install failed.
unreferenced object 0xffff88810bc28520 (size 16):
comm "modprobe", pid 9662, jiffies 4298009455 (age 42.590s)
hex dump (first 16 bytes):
01 01 00 64 81 88 ff ff 00 00 dc 0a 81 88 ff ff ...d............
backtrace:
[<00000000e7561ff8>] kmalloc_trace+0x27/0x60
[<000000000b1954a0>] 0xffffffffc45200a9
[<00000000abbf1da0>] do_one_initcall+0xd0/0x4f0
[<000000001505ee87>] do_init_module+0x1a4/0x680
[<00000000958079ad>] load_module+0x6249/0x7110
[<00000000117e4696>] __do_sys_finit_module+0x140/0x200
[<00000000f74b12d2>] do_syscall_64+0x35/0x80
[<000000008fc6fcde>] entry_SYSCALL_64_after_hwframe+0x46/0xb0
The reason is that the vkms_init() returns without checking the return
value of vkms_create(), and if the vkms_create() failed, the config
allocated at the beginning of vkms_init() is leaked.
vkms_init()
config = kmalloc(...) # config allocated
...
return vkms_create() # vkms_create failed and config is leaked
Fix this problem by checking return value of vkms_create() and free the
config if error happened. |
| 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. |
| In the Linux kernel, the following vulnerability has been resolved:
ubi: Fix unreferenced object reported by kmemleak in ubi_resize_volume()
There is a memory leaks problem reported by kmemleak:
unreferenced object 0xffff888102007a00 (size 128):
comm "ubirsvol", pid 32090, jiffies 4298464136 (age 2361.231s)
hex dump (first 32 bytes):
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
backtrace:
[<ffffffff8176cecd>] __kmalloc+0x4d/0x150
[<ffffffffa02a9a36>] ubi_eba_create_table+0x76/0x170 [ubi]
[<ffffffffa029764e>] ubi_resize_volume+0x1be/0xbc0 [ubi]
[<ffffffffa02a3321>] ubi_cdev_ioctl+0x701/0x1850 [ubi]
[<ffffffff81975d2d>] __x64_sys_ioctl+0x11d/0x170
[<ffffffff83c142a5>] do_syscall_64+0x35/0x80
[<ffffffff83e0006a>] entry_SYSCALL_64_after_hwframe+0x46/0xb0
This is due to a mismatch between create and destroy interfaces, and
in detail that "new_eba_tbl" created by ubi_eba_create_table() but
destroyed by kfree(), while will causing "new_eba_tbl->entries" not
freed.
Fix it by replacing kfree(new_eba_tbl) with
ubi_eba_destroy_table(new_eba_tbl) |
| In the Linux kernel, the following vulnerability has been resolved:
ubifs: Free memory for tmpfile name
When opening a ubifs tmpfile on an encrypted directory, function
fscrypt_setup_filename allocates memory for the name that is to be
stored in the directory entry, but after the name has been copied to the
directory entry inode, the memory is not freed.
When running kmemleak on it we see that it is registered as a leak. The
report below is triggered by a simple program 'tmpfile' just opening a
tmpfile:
unreferenced object 0xffff88810178f380 (size 32):
comm "tmpfile", pid 509, jiffies 4294934744 (age 1524.742s)
backtrace:
__kmem_cache_alloc_node
__kmalloc
fscrypt_setup_filename
ubifs_tmpfile
vfs_tmpfile
path_openat
Free this memory after it has been copied to the inode. |
| In the Linux kernel, the following vulnerability has been resolved:
ubifs: Fix memory leak in ubifs_sysfs_init()
When insmod ubifs.ko, a kmemleak reported as below:
unreferenced object 0xffff88817fb1a780 (size 8):
comm "insmod", pid 25265, jiffies 4295239702 (age 100.130s)
hex dump (first 8 bytes):
75 62 69 66 73 00 ff ff ubifs...
backtrace:
[<ffffffff81b3fc4c>] slab_post_alloc_hook+0x9c/0x3c0
[<ffffffff81b44bf3>] __kmalloc_track_caller+0x183/0x410
[<ffffffff8198d3da>] kstrdup+0x3a/0x80
[<ffffffff8198d486>] kstrdup_const+0x66/0x80
[<ffffffff83989325>] kvasprintf_const+0x155/0x190
[<ffffffff83bf55bb>] kobject_set_name_vargs+0x5b/0x150
[<ffffffff83bf576b>] kobject_set_name+0xbb/0xf0
[<ffffffff8100204c>] do_one_initcall+0x14c/0x5a0
[<ffffffff8157e380>] do_init_module+0x1f0/0x660
[<ffffffff815857be>] load_module+0x6d7e/0x7590
[<ffffffff8158644f>] __do_sys_finit_module+0x19f/0x230
[<ffffffff815866b3>] __x64_sys_finit_module+0x73/0xb0
[<ffffffff88c98e85>] do_syscall_64+0x35/0x80
[<ffffffff88e00087>] entry_SYSCALL_64_after_hwframe+0x63/0xcd
When kset_register() failed, we should call kset_put to cleanup it. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/client: Fix memory leak in drm_client_modeset_probe
When a new mode is set to modeset->mode, the previous mode should be freed.
This fixes the following kmemleak report:
drm_mode_duplicate+0x45/0x220 [drm]
drm_client_modeset_probe+0x944/0xf50 [drm]
__drm_fb_helper_initial_config_and_unlock+0xb4/0x2c0 [drm_kms_helper]
drm_fbdev_client_hotplug+0x2bc/0x4d0 [drm_kms_helper]
drm_client_register+0x169/0x240 [drm]
ast_pci_probe+0x142/0x190 [ast]
local_pci_probe+0xdc/0x180
work_for_cpu_fn+0x4e/0xa0
process_one_work+0x8b7/0x1540
worker_thread+0x70a/0xed0
kthread+0x29f/0x340
ret_from_fork+0x1f/0x30 |
| In the Linux kernel, the following vulnerability has been resolved:
samples/bpf: Fix fout leak in hbm's run_bpf_prog
Fix fout being fopen'ed but then not subsequently fclose'd. In the affected
branch, fout is otherwise going out of scope. |
| In the Linux kernel, the following vulnerability has been resolved:
driver: soc: xilinx: fix memory leak in xlnx_add_cb_for_notify_event()
The kfree() should be called when memory fails to be allocated for
cb_data in xlnx_add_cb_for_notify_event(), otherwise there will be
a memory leak, so add kfree() to fix it. |
| In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix memleak due to fentry attach failure
If it fails to attach fentry, the allocated bpf trampoline image will be
left in the system. That can be verified by checking /proc/kallsyms.
This meamleak can be verified by a simple bpf program as follows:
SEC("fentry/trap_init")
int fentry_run()
{
return 0;
}
It will fail to attach trap_init because this function is freed after
kernel init, and then we can find the trampoline image is left in the
system by checking /proc/kallsyms.
$ tail /proc/kallsyms
ffffffffc0613000 t bpf_trampoline_6442453466_1 [bpf]
ffffffffc06c3000 t bpf_trampoline_6442453466_1 [bpf]
$ bpftool btf dump file /sys/kernel/btf/vmlinux | grep "FUNC 'trap_init'"
[2522] FUNC 'trap_init' type_id=119 linkage=static
$ echo $((6442453466 & 0x7fffffff))
2522
Note that there are two left bpf trampoline images, that is because the
libbpf will fallback to raw tracepoint if -EINVAL is returned. |
| In the Linux kernel, the following vulnerability has been resolved:
misc: vmw_balloon: 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:
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:
clk: imx: clk-imxrt1050: fix memory leak in imxrt1050_clocks_probe
Use devm_of_iomap() instead of of_iomap() to automatically
handle the unused ioremap region. If any error occurs, regions allocated by
kzalloc() will leak, but using devm_kzalloc() instead will automatically
free the memory using devm_kfree().
Also, fix error handling of hws by adding unregister_hws label, which
unregisters remaining hws when iomap failed. |
| In the Linux kernel, the following vulnerability has been resolved:
arm64: acpi: Fix possible memory leak of ffh_ctxt
Allocated 'ffh_ctxt' memory leak is possible if the SMCCC version
and conduit checks fail and -EOPNOTSUPP is returned without freeing the
allocated memory.
Fix the same by moving the allocation after the SMCCC version and
conduit checks. |
| In the Linux kernel, the following vulnerability has been resolved:
net: microchip: vcap api: Fix possible memory leak for vcap_dup_rule()
Inject fault When select CONFIG_VCAP_KUNIT_TEST, the below memory leak
occurs. If kzalloc() for duprule succeeds, but the following
kmemdup() fails, the duprule, ckf and caf memory will be leaked. So kfree
them in the error path.
unreferenced object 0xffff122744c50600 (size 192):
comm "kunit_try_catch", pid 346, jiffies 4294896122 (age 911.812s)
hex dump (first 32 bytes):
10 27 00 00 04 00 00 00 1e 00 00 00 2c 01 00 00 .'..........,...
00 00 00 00 00 00 00 00 18 06 c5 44 27 12 ff ff ...........D'...
backtrace:
[<00000000394b0db8>] __kmem_cache_alloc_node+0x274/0x2f8
[<0000000001bedc67>] kmalloc_trace+0x38/0x88
[<00000000b0612f98>] vcap_dup_rule+0x50/0x460
[<000000005d2d3aca>] vcap_add_rule+0x8cc/0x1038
[<00000000eef9d0f8>] test_vcap_xn_rule_creator.constprop.0.isra.0+0x238/0x494
[<00000000cbda607b>] vcap_api_rule_remove_in_front_test+0x1ac/0x698
[<00000000c8766299>] kunit_try_run_case+0xe0/0x20c
[<00000000c4fe9186>] kunit_generic_run_threadfn_adapter+0x50/0x94
[<00000000f6864acf>] kthread+0x2e8/0x374
[<0000000022e639b3>] ret_from_fork+0x10/0x20 |
| In the Linux kernel, the following vulnerability has been resolved:
media: hi846: Fix memleak in hi846_init_controls()
hi846_init_controls doesn't clean the allocated ctrl_hdlr
in case there is a failure, which causes memleak. Add
v4l2_ctrl_handler_free to free the resource properly. |
| In the Linux kernel, the following vulnerability has been resolved:
md/raid10: fix leak of 'r10bio->remaining' for recovery
raid10_sync_request() will add 'r10bio->remaining' for both rdev and
replacement rdev. However, if the read io fails, recovery_request_write()
returns without issuing the write io, in this case, end_sync_request()
is only called once and 'remaining' is leaked, cause an io hang.
Fix the problem by decreasing 'remaining' according to if 'bio' and
'repl_bio' is valid. |
| In the Linux kernel, the following vulnerability has been resolved:
nfc: fix memory leak of se_io context in nfc_genl_se_io
The callback context for sending/receiving APDUs to/from the selected
secure element is allocated inside nfc_genl_se_io and supposed to be
eventually freed in se_io_cb callback function. However, there are several
error paths where the bwi_timer is not charged to call se_io_cb later, and
the cb_context is leaked.
The patch proposes to free the cb_context explicitly on those error paths.
At the moment we can't simply check 'dev->ops->se_io()' return value as it
may be negative in both cases: when the timer was charged and was not. |
| In the Linux kernel, the following vulnerability has been resolved:
clk: socfpga: Fix memory leak in socfpga_gate_init()
Free @socfpga_clk and @ops on the error path to avoid memory leak issue. |
| In the Linux kernel, the following vulnerability has been resolved:
vdpasim: fix memory leak when freeing IOTLBs
After commit bda324fd037a ("vdpasim: control virtqueue support"),
vdpasim->iommu became an array of IOTLB, so we should clean the
mappings of each free one by one instead of just deleting the ranges
in the first IOTLB which may leak maps. |
