CVE-2025-40341 Affecting ocfs2-kmp-default package, versions <6.4.0-150700.53.66.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 applications- Snyk IDSNYK-SLES157-OCFS2KMPDEFAULT-17901826
- published9 Jul 2026
- disclosed8 Jul 2026
Introduced: 8 Jul 2026
NewCVE-2025-40341 (opens in a new tab)How to fix?
Upgrade SLES:15.7 ocfs2-kmp-default to version 6.4.0-150700.53.66.1 or higher.
NVD Description
Note: Versions mentioned in the description apply only to the upstream ocfs2-kmp-default package and not the ocfs2-kmp-default package as distributed by SLES.
See How to fix? for SLES:15.7 relevant fixed versions and status.
In the Linux kernel, the following vulnerability has been resolved:
futex: Don't leak robust_list pointer on exec race
sys_get_robust_list() and compat_get_robust_list() use ptrace_may_access() to check if the calling task is allowed to access another task's robust_list pointer. This check is racy against a concurrent exec() in the target process.
During exec(), a task may transition from a non-privileged binary to a privileged one (e.g., setuid binary) and its credentials/memory mappings may change. If get_robust_list() performs ptrace_may_access() before this transition, it may erroneously allow access to sensitive information after the target becomes privileged.
A racy access allows an attacker to exploit a window during which ptrace_may_access() passes before a target process transitions to a privileged state via exec().
For example, consider a non-privileged task T that is about to execute a setuid-root binary. An attacker task A calls get_robust_list(T) while T is still unprivileged. Since ptrace_may_access() checks permissions based on current credentials, it succeeds. However, if T begins exec immediately afterwards, it becomes privileged and may change its memory mappings. Because get_robust_list() proceeds to access T->robust_list without synchronizing with exec() it may read user-space pointers from a now-privileged process.
This violates the intended post-exec access restrictions and could expose sensitive memory addresses or be used as a primitive in a larger exploit chain. Consequently, the race can lead to unauthorized disclosure of information across privilege boundaries and poses a potential security risk.
Take a read lock on signal->exec_update_lock prior to invoking ptrace_may_access() and accessing the robust_list/compat_robust_list. This ensures that the target task's exec state remains stable during the check, allowing for consistent and synchronized validation of credentials.
References
- https://www.suse.com/security/cve/CVE-2025-40341.html
- https://bugzilla.suse.com/1255029
- https://git.kernel.org/stable/c/3b4222494489f6d4b8705a496dab03384b7ca998
- https://git.kernel.org/stable/c/4aced32596ead1820b7dbd8e40d30b30dc1f3ad4
- https://git.kernel.org/stable/c/6511984d1aa1360181bcafb1ca75df7f291ef237
- https://git.kernel.org/stable/c/6b54082c3ed4dc9821cdf0edb17302355cc5bb45
- https://git.kernel.org/stable/c/b524455a51feb6013df3a5dba3160487b2e8e22a