Memory Leak Affecting kernel-uki-virt-addons package, versions *
Threat Intelligence
The probability is the direct output of the EPSS model, and conveys an overall sense of the threat of exploitation in the wild. The percentile measures the EPSS probability relative to all known EPSS scores. Note: This data is updated daily, relying on the latest available EPSS model version. Check out the EPSS documentation for more details.
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 IDSNYK-RHEL9-KERNELUKIVIRTADDONS-8423573
- published27 Nov 2024
- disclosed21 Oct 2024
Introduced: 21 Oct 2024
CVE-2024-49870 (opens in a new tab)How to fix?
There is no fixed version for RHEL:9 kernel-uki-virt-addons.
NVD Description
Note: Versions mentioned in the description apply only to the upstream kernel-uki-virt-addons package and not the kernel-uki-virt-addons package as distributed by RHEL.
See How to fix? for RHEL:9 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