CVE-2024-56586 Affecting kernel-uek-container package, versions <0:5.15.0-305.176.4.el9uek
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-ORACLE9-KERNELUEKCONTAINER-8711448
- published12 Feb 2025
- disclosed27 Dec 2024
Introduced: 27 Dec 2024
CVE-2024-56586 (opens in a new tab)How to fix?
Upgrade Oracle:9 kernel-uek-container to version 0:5.15.0-305.176.4.el9uek or higher.
This issue was patched in ELSA-2025-20095.
NVD Description
Note: Versions mentioned in the description apply only to the upstream kernel-uek-container package and not the kernel-uek-container package as distributed by Oracle.
See How to fix? for Oracle:9 relevant fixed versions and status.
In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix f2fs_bug_on when uninstalling filesystem call f2fs_evict_inode.
creating a large files during checkpoint disable until it runs out of space and then delete it, then remount to enable checkpoint again, and then unmount the filesystem triggers the f2fs_bug_on as below:
------------[ cut here ]------------ kernel BUG at fs/f2fs/inode.c:896! CPU: 2 UID: 0 PID: 1286 Comm: umount Not tainted 6.11.0-rc7-dirty #360 Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI RIP: 0010:f2fs_evict_inode+0x58c/0x610 Call Trace: __die_body+0x15/0x60 die+0x33/0x50 do_trap+0x10a/0x120 f2fs_evict_inode+0x58c/0x610 do_error_trap+0x60/0x80 f2fs_evict_inode+0x58c/0x610 exc_invalid_op+0x53/0x60 f2fs_evict_inode+0x58c/0x610 asm_exc_invalid_op+0x16/0x20 f2fs_evict_inode+0x58c/0x610 evict+0x101/0x260 dispose_list+0x30/0x50 evict_inodes+0x140/0x190 generic_shutdown_super+0x2f/0x150 kill_block_super+0x11/0x40 kill_f2fs_super+0x7d/0x140 deactivate_locked_super+0x2a/0x70 cleanup_mnt+0xb3/0x140 task_work_run+0x61/0x90
The root cause is: creating large files during disable checkpoint period results in not enough free segments, so when writing back root inode will failed in f2fs_enable_checkpoint. When umount the file system after enabling checkpoint, the root inode is dirty in f2fs_evict_inode function, which triggers BUG_ON. The steps to reproduce are as follows:
dd if=/dev/zero of=f2fs.img bs=1M count=55 mount f2fs.img f2fs_dir -o checkpoint=disable:10% dd if=/dev/zero of=big bs=1M count=50 sync rm big mount -o remount,checkpoint=enable f2fs_dir umount f2fs_dir
Let's redirty inode when there is not free segments during checkpoint is disable.
References
- https://linux.oracle.com/cve/CVE-2024-56586.html
- https://linux.oracle.com/errata/ELSA-2025-20095.html
- https://git.kernel.org/stable/c/9669b28f81e0ec6305af7773846fbe2cef1e7d61
- https://git.kernel.org/stable/c/9e28513fd2858911dcf47b84160a8824587536b6
- https://git.kernel.org/stable/c/a365de2fbfbe1e6740bfb75ab5c3245cf7bbe4d7
- https://git.kernel.org/stable/c/ac8aaf78bd039fa1be0acaa8e84a56499f79d721
- https://git.kernel.org/stable/c/d5c367ef8287fb4d235c46a2f8c8d68715f3a0ca
- https://git.kernel.org/stable/c/dff561e4060d28edc9a2960d4a87f3c945a96aa3
- https://git.kernel.org/stable/c/ef517d2d21c3d8e2ad35b2bb728bd1c90a31e617