Race Condition Affecting kernel-doc package, versions *


Severity

Recommended
medium

Based on CentOS security rating.

Threat Intelligence

EPSS
0.15% (5th percentile)

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-KERNELDOC-17773570
  • published2 Jul 2026
  • disclosed1 Jul 2026

Introduced: 1 Jul 2026

NewCVE-2026-53341  (opens in a new tab)
CWE-364  (opens in a new tab)

How to fix?

There is no fixed version for Centos:10 kernel-doc.

NVD Description

Note: Versions mentioned in the description apply only to the upstream kernel-doc package and not the kernel-doc 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:

fhandle: fix UAF due to unlocked ->mnt_ns read in may_decode_fh()

may_decode_fh() accesses mount::mnt_ns without holding any locks; that means the mount can concurrently be unmounted, and the mnt_namespace can concurrently be freed after an RCU grace period.

This race can happens as follows, assuming that the mount point was created by open_tree(..., OPEN_TREE_CLONE):

thread 1 thread 2 RCU __do_sys_open_by_handle_at do_handle_open handle_to_path may_decode_fh is_mounted [mount::mnt_ns access] [mount::mnt_ns access] __do_sys_close fput_close_sync __fput dissolve_on_fput umount_tree class_namespace_excl_destructor namespace_unlock free_mnt_ns mnt_ns_tree_remove call_rcu(mnt_ns_release_rcu) mnt_ns_release_rcu mnt_ns_release kfree [mnt_namespace::user_ns access] UAF

Fix it by taking rcu_read_lock() around the mount::mnt_ns access, like in __prepend_path(). Additionally, document the semantics of mount::mnt_ns, and use WRITE_ONCE() for writers that can race with lockless readers.

This bug is unreachable unless one of the following is set:

  • CONFIG_PREEMPTION
  • CONFIG_RCU_STRICT_GRACE_PERIOD

because it requires an RCU grace period to happen during a syscall without an explicit preemption.

This doesn't seem to have interesting security impact; worst-case, it could leak the result of an integer comparison to userspace (from the level check in cap_capable()), cause an endless loop, or crash the kernel by dereferencing an invalid address.

CVSS Base Scores

version 3.1