Reachable Assertion Affecting kernel-64k-debug package, versions *
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-CENTOS10-KERNEL64KDEBUG-19249050
- published25 Aug 2026
- disclosed22 Aug 2026
Introduced: 22 Aug 2026
NewCVE-2026-74619 (opens in a new tab)How to fix?
There is no fixed version for Centos:10 kernel-64k-debug.
NVD Description
Note: Versions mentioned in the description apply only to the upstream kernel-64k-debug package and not the kernel-64k-debug package as distributed by Centos.
See How to fix? for Centos:10 relevant fixed versions and status.
In the Linux kernel, the following vulnerability has been resolved:
ovl: don't warn when the mount is completed from another user namespace
fsopen() records the caller's user namespace in fc->user_ns and hands back an ordinary file descriptor. Nothing ties the task that calls fsconfig(FSCONFIG_CMD_CREATE) to the task that created the context. The fd is inherited across fork() and exec() and it can be passed over a unix socket.
Completing a context from another user namespace is allowed on purpose. vfs_cmd_create() authorizes the create with mount_capable(), which for FS_USERNS_MOUNT checks ns_capable(fc->user_ns, CAP_SYS_ADMIN), and that succeeds for a task holding CAP_SYS_ADMIN in an ancestor of fc->user_ns. So an unprivileged task can reach the WARN_ON() in ovl_fill_super(): create a user and a mount namespace in a child, call fsopen("overlay") there, send the fscontext fd to the parent and let the parent issue FSCONFIG_CMD_CREATE. Both namespaces come from a plain unshare(1) and no capability is needed anywhere:
WARNING: fs/overlayfs/super.c:1551 at ovl_fill_super+0x7b9/0x1e20 [overlay] CPU: 3 UID: 1000 PID: 3243376 Comm: fswarn Call Trace: get_tree_nodev+0x71/0xa0 ovl_get_tree+0x15/0x20 [overlay] vfs_get_tree+0x2a/0x100 vfs_cmd_create+0x60/0xf0 __do_sys_fsconfig+0x4b2/0x500
The child needs the mount namespace because fsopen() itself gates on may_mount(), which asks for CAP_SYS_ADMIN in the user namespace owning the caller's mount namespace. fsconfig() doesn't repeat that check.
It is a WARN_ON() and not a WARN_ON_ONCE(), so the condition can be raised in a loop to taint the kernel and flood the log, and it panics a kernel booted with panic_on_warn.
Keep refusing the mount and stop warning about it. ovl_parse_param() already spells a user namespace check this way for Opt_override_creds.
References
- https://bugzilla.redhat.com/show_bug.cgi?id=2521447
- https://access.redhat.com/security/cve/CVE-2026-74619
- https://git.kernel.org/stable/c/42d99fcd8006007e2f708bede6789f37f3910b30
- https://git.kernel.org/stable/c/494346f2aab2489d379d43ff614aea447cf4e94d
- https://git.kernel.org/stable/c/513478092966dc9818d96dd2b3ed613fd2f6e30e
- https://git.kernel.org/stable/c/63981fc786daaa626cb14d9be1406f674d79f98f
- https://git.kernel.org/stable/c/be161fa31e3e9cc828a3c1bd935edca461e8a7a1