CVE-2024-47669 Affecting kernel-uek-debug-core package, versions <0:5.15.0-302.167.6.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-KERNELUEKDEBUGCORE-8374507
- published14 Nov 2024
- disclosed9 Oct 2024
Introduced: 9 Oct 2024
CVE-2024-47669 (opens in a new tab)How to fix?
Upgrade Oracle:9 kernel-uek-debug-core to version 0:5.15.0-302.167.6.el9uek or higher.
This issue was patched in ELSA-2024-12815.
NVD Description
Note: Versions mentioned in the description apply only to the upstream kernel-uek-debug-core package and not the kernel-uek-debug-core 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:
nilfs2: fix state management in error path of log writing function
After commit a694291a6211 ("nilfs2: separate wait function from nilfs_segctor_write") was applied, the log writing function nilfs_segctor_do_construct() was able to issue I/O requests continuously even if user data blocks were split into multiple logs across segments, but two potential flaws were introduced in its error handling.
First, if nilfs_segctor_begin_construction() fails while creating the second or subsequent logs, the log writing function returns without calling nilfs_segctor_abort_construction(), so the writeback flag set on pages/folios will remain uncleared. This causes page cache operations to hang waiting for the writeback flag. For example, truncate_inode_pages_final(), which is called via nilfs_evict_inode() when an inode is evicted from memory, will hang.
Second, the NILFS_I_COLLECTED flag set on normal inodes remain uncleared. As a result, if the next log write involves checkpoint creation, that's fine, but if a partial log write is performed that does not, inodes with NILFS_I_COLLECTED set are erroneously removed from the "sc_dirty_files" list, and their data and b-tree blocks may not be written to the device, corrupting the block mapping.
Fix these issues by uniformly calling nilfs_segctor_abort_construction() on failure of each step in the loop in nilfs_segctor_do_construct(), having it clean up logs and segment usages according to progress, and correcting the conditions for calling nilfs_redirty_inodes() to ensure that the NILFS_I_COLLECTED flag is cleared.
References
- https://linux.oracle.com/cve/CVE-2024-47669.html
- https://linux.oracle.com/errata/ELSA-2024-12813.html
- https://linux.oracle.com/errata/ELSA-2024-12815.html
- https://linux.oracle.com/errata/ELSA-2024-12868.html
- https://git.kernel.org/stable/c/036441e8438b29111fa75008f0ce305fb4e83c0a
- https://git.kernel.org/stable/c/0a1a961bde4351dc047ffdeb2f1311ca16a700cc
- https://git.kernel.org/stable/c/30562eff4a6dd35c4b5be9699ef61ad9f5f20a06
- https://git.kernel.org/stable/c/3e349d7191f0688fc9808ef24fd4e4b4ef5ca876
- https://git.kernel.org/stable/c/40a2757de2c376ef8a08d9ee9c81e77f3c750adf
- https://git.kernel.org/stable/c/6576dd6695f2afca3f4954029ac4a64f82ba60ab
- https://git.kernel.org/stable/c/74866c16ea2183f52925fa5d76061a1fe7f7737b
- https://git.kernel.org/stable/c/efdde00d4a1ef10bb71e09ebc67823a3d3ad725b