NULL Pointer Dereference Affecting kernel-source-coco package, versions <6.4.0-15061.21.coco15sp6.1
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-SLES156-KERNELSOURCECOCO-10349224
- published13 Jun 2025
- disclosed12 Jun 2025
Introduced: 12 Jun 2025
NewCVE-2025-22070 (opens in a new tab)How to fix?
Upgrade SLES:15.6 kernel-source-coco to version 6.4.0-15061.21.coco15sp6.1 or higher.
NVD Description
Note: Versions mentioned in the description apply only to the upstream kernel-source-coco package and not the kernel-source-coco package as distributed by SLES.
See How to fix? for SLES:15.6 relevant fixed versions and status.
In the Linux kernel, the following vulnerability has been resolved:
fs/9p: fix NULL pointer dereference on mkdir
When a 9p tree was mounted with option 'posixacl', parent directory had a default ACL set for its subdirectories, e.g.:
setfacl -m default:group:simpsons:rwx parentdir
then creating a subdirectory crashed 9p client, as v9fs_fid_add() call in function v9fs_vfs_mkdir_dotl() sets the passed 'fid' pointer to NULL (since dafbe689736) even though the subsequent v9fs_set_create_acl() call expects a valid non-NULL 'fid' pointer:
[ 37.273191] BUG: kernel NULL pointer dereference, address: 0000000000000000 ... [ 37.322338] Call Trace: [ 37.323043] <TASK> [ 37.323621] ? __die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434) [ 37.324448] ? page_fault_oops (arch/x86/mm/fault.c:714) [ 37.325532] ? search_module_extables (kernel/module/main.c:3733) [ 37.326742] ? p9_client_walk (net/9p/client.c:1165) 9pnet [ 37.328006] ? search_bpf_extables (kernel/bpf/core.c:804) [ 37.329142] ? exc_page_fault (./arch/x86/include/asm/paravirt.h:686 arch/x86/mm/fault.c:1488 arch/x86/mm/fault.c:1538) [ 37.330196] ? asm_exc_page_fault (./arch/x86/include/asm/idtentry.h:574) [ 37.331330] ? p9_client_walk (net/9p/client.c:1165) 9pnet [ 37.332562] ? v9fs_fid_xattr_get (fs/9p/xattr.c:30) 9p [ 37.333824] v9fs_fid_xattr_set (fs/9p/fid.h:23 fs/9p/xattr.c:121) 9p [ 37.335077] v9fs_set_acl (fs/9p/acl.c:276) 9p [ 37.336112] v9fs_set_create_acl (fs/9p/acl.c:307) 9p [ 37.337326] v9fs_vfs_mkdir_dotl (fs/9p/vfs_inode_dotl.c:411) 9p [ 37.338590] vfs_mkdir (fs/namei.c:4313) [ 37.339535] do_mkdirat (fs/namei.c:4336) [ 37.340465] __x64_sys_mkdir (fs/namei.c:4354) [ 37.341455] do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83) [ 37.342447] entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
Fix this by simply swapping the sequence of these two calls in v9fs_vfs_mkdir_dotl(), i.e. calling v9fs_set_create_acl() before v9fs_fid_add().
References
- https://www.suse.com/security/cve/CVE-2025-22070.html
- https://bugzilla.suse.com/1241305
- https://git.kernel.org/stable/c/2139dea5c53e3bb63ac49a6901c85e525a80ee8a
- https://git.kernel.org/stable/c/3f61ac7c65bdb26accb52f9db66313597e759821
- https://git.kernel.org/stable/c/6517b395cb1e43fbf3962dd93e6fb4a5e5ab100e
- https://git.kernel.org/stable/c/8522051c58d68146b93e8a5ba9987e83b3d64e7b