NULL Pointer Dereference Affecting kernel-uek-doc package, versions <0:6.12.0-103.40.4.1.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 applicationsSnyk Learn
Learn about NULL Pointer Dereference vulnerabilities in an interactive lesson.
Start learning- Snyk IDSNYK-ORACLE9-KERNELUEKDOC-12564237
- published9 Sept 2025
- disclosed3 Jul 2025
Introduced: 3 Jul 2025
CVE-2025-38163 (opens in a new tab)How to fix?
Upgrade Oracle:9 kernel-uek-doc to version 0:6.12.0-103.40.4.1.el9uek or higher.
This issue was patched in ELSA-2025-20551.
NVD Description
Note: Versions mentioned in the description apply only to the upstream kernel-uek-doc package and not the kernel-uek-doc 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 to do sanity check on sbi->total_valid_block_count
syzbot reported a f2fs bug as below:
------------[ cut here ]------------ kernel BUG at fs/f2fs/f2fs.h:2521! RIP: 0010:dec_valid_block_count+0x3b2/0x3c0 fs/f2fs/f2fs.h:2521 Call Trace: f2fs_truncate_data_blocks_range+0xc8c/0x11a0 fs/f2fs/file.c:695 truncate_dnode+0x417/0x740 fs/f2fs/node.c:973 truncate_nodes+0x3ec/0xf50 fs/f2fs/node.c:1014 f2fs_truncate_inode_blocks+0x8e3/0x1370 fs/f2fs/node.c:1197 f2fs_do_truncate_blocks+0x840/0x12b0 fs/f2fs/file.c:810 f2fs_truncate_blocks+0x10d/0x300 fs/f2fs/file.c:838 f2fs_truncate+0x417/0x720 fs/f2fs/file.c:888 f2fs_setattr+0xc4f/0x12f0 fs/f2fs/file.c:1112 notify_change+0xbca/0xe90 fs/attr.c:552 do_truncate+0x222/0x310 fs/open.c:65 handle_truncate fs/namei.c:3466 [inline] do_open fs/namei.c:3849 [inline] path_openat+0x2e4f/0x35d0 fs/namei.c:4004 do_filp_open+0x284/0x4e0 fs/namei.c:4031 do_sys_openat2+0x12b/0x1d0 fs/open.c:1429 do_sys_open fs/open.c:1444 [inline] __do_sys_creat fs/open.c:1522 [inline] __se_sys_creat fs/open.c:1516 [inline] __x64_sys_creat+0x124/0x170 fs/open.c:1516 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/syscall_64.c:94
The reason is: in fuzzed image, sbi->total_valid_block_count is inconsistent w/ mapped blocks indexed by inode, so, we should not trigger panic for such case, instead, let's print log and set fsck flag.
References
- https://linux.oracle.com/cve/CVE-2025-38163.html
- https://linux.oracle.com/errata/ELSA-2025-20551.html
- https://linux.oracle.com/errata/ELSA-2025-20552.html
- https://git.kernel.org/stable/c/05872a167c2cab80ef186ef23cc34a6776a1a30c
- https://git.kernel.org/stable/c/25f3776b58c1c45ad2e50ab4b263505b4d2378ca
- https://git.kernel.org/stable/c/49bc7bf38e42cfa642787e947f5721696ea73ac3
- https://git.kernel.org/stable/c/65b3f76592aed5a43c4d79375ac097acf975972b
- https://git.kernel.org/stable/c/6a324d77f7ea1a91d55c4b6ad970e3ac9ab6a20d
- https://git.kernel.org/stable/c/a39cc43efc1bca74ed9d6cf9e60b995071f7d178
- https://git.kernel.org/stable/c/ccc28c0397f75a3ec9539cceed9db014d7b73869
- https://git.kernel.org/stable/c/f1b743c1955151bd392539b739a3ad155296be13
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html