Memory Leak Affecting kernel-bootwrapper package, versions *
Threat Intelligence
Do your applications use this vulnerable package?
In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.
Test your applications- Snyk ID SNYK-RHEL7-KERNELBOOTWRAPPER-8240174
- published 22 Oct 2024
- disclosed 21 Oct 2024
Introduced: 21 Oct 2024
CVE-2024-49870 Open this link in a new tabHow to fix?
There is no fixed version for RHEL:7
kernel-bootwrapper
.
NVD Description
Note: Versions mentioned in the description apply only to the upstream kernel-bootwrapper
package and not the kernel-bootwrapper
package as distributed by RHEL
.
See How to fix?
for RHEL:7
relevant fixed versions and status.
In the Linux kernel, the following vulnerability has been resolved:
cachefiles: fix dentry leak in cachefiles_open_file()
A dentry leak may be caused when a lookup cookie and a cull are concurrent:
P1 | P2
cachefiles_lookup_cookie cachefiles_look_up_object lookup_one_positive_unlocked // get dentry cachefiles_cull inode->i_flags |= S_KERNEL_FILE; cachefiles_open_file cachefiles_mark_inode_in_use __cachefiles_mark_inode_in_use can_use = false if (!(inode->i_flags & S_KERNEL_FILE)) can_use = true return false return false // Returns an error but doesn't put dentry
After that the following WARNING will be triggered when the backend folder is umounted:
================================================================== BUG: Dentry 000000008ad87947{i=7a,n=Dx_1_1.img} still in use (1) [unmount of ext4 sda] WARNING: CPU: 4 PID: 359261 at fs/dcache.c:1767 umount_check+0x5d/0x70 CPU: 4 PID: 359261 Comm: umount Not tainted 6.6.0-dirty #25 RIP: 0010:umount_check+0x5d/0x70 Call Trace: <TASK> d_walk+0xda/0x2b0 do_one_tree+0x20/0x40 shrink_dcache_for_umount+0x2c/0x90 generic_shutdown_super+0x20/0x160 kill_block_super+0x1a/0x40 ext4_kill_sb+0x22/0x40 deactivate_locked_super+0x35/0x80 cleanup_mnt+0x104/0x160
Whether cachefiles_open_file() returns true or false, the reference count obtained by lookup_positive_unlocked() in cachefiles_look_up_object() should be released.
Therefore release that reference count in cachefiles_look_up_object() to fix the above issue and simplify the code.
References
- https://access.redhat.com/security/cve/CVE-2024-49870
- https://git.kernel.org/stable/c/7fa2382f97421978514a419c93054eca69f5247b
- https://git.kernel.org/stable/c/c7d10fa7d7691558ff967668494672415f5fa151
- https://git.kernel.org/stable/c/d32ff64c872d7e08e893c32ba6a2374583444410
- https://git.kernel.org/stable/c/da6ef2dffe6056aad3435e6cf7c6471c2a62187c
- https://git.kernel.org/stable/c/e4a28489b310339b2b8187bec0a437709be551c1