| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
USB: dwc3: 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.
Note, the root dentry for the debugfs directory for the device needs to
be saved so we don't have to keep looking it up, which required a bit
more refactoring to properly create and remove it when needed. |
| In the Linux kernel, the following vulnerability has been resolved:
scsi: snic: 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:
USB: isp116x: 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:
USB: gadget: bcm63xx_udc: 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:
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:
USB: ULPI: 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:
drivers: base: component: 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:
trace/blktrace: 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:
USB: gadget: pxa27x_udc: 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:
kernel/fail_function: 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:
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. |
| A flaw was found in the quarkus-resteasy extension, which causes memory leaks when client requests with low timeouts are made. If a client request times out, a buffer is not released correctly, leading to increased memory usage and eventual application crash due to OutOfMemoryError. |
| 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. |
| In the Linux kernel, the following vulnerability has been resolved:
USB: chipidea: 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. |
| 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. |
