Cloudanix VulnDB

CVE-2025-38306

None

CVSS

—

EPSS

0.1%

Published

Jul 10, 2025

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in the Linux kernel can let certain file operations race with each other and crash the whole system.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Race Condition
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

Race condition in may_decode_fh() allowing unsynchronized call to has_locked_children() without holding mount_lock or namespace_sem, leading to potential use-after-free or invalid mount reference and kernel oops.

Why it matters to the business

Linux kernel crashes or system instability on affected distributions can interrupt services, cause data loss during operations, and require reboots; prevalence across many Linux deployments increases operational risk.

How an attack unfolds

An attacker with local access triggers concurrent filesystem handle decoding operations while the kernel performs mount namespace changes; the missing lock allows the race window to dereference an invalid mount structure, resulting in a crash.

How to fix it

Upgrade to fixed kernel versions: linux-lts 6.1.81-r0 or later, 6.6.58-r0 or later, 6.12.41-r0 or later, or mainline commit 6482c3dccbfb8d20e2856ce67c75856859930b3f; apply vendor patches and reboot.

How to confirm the fix worked

Confirm kernel version is at or above the listed fixed releases; review fs/fhandle.c and fs/namespace.c for presence of the __has_locked_children wrapper under read_seqlock_excl(&mount_lock); test with concurrent fhandle and mount operations.

Typical attack path

  1. Obtain local unprivileged access on affected Linux system
  2. Perform concurrent NFS file handle decode and mount namespace manipulation operations
  3. Trigger the unsynchronized has_locked_children() path to hit the race
  4. Cause kernel oops and potential denial of service

How to detect it

Review kernel logs for oops traces referencing has_locked_children, may_decode_fh, or fhandle.c; correlate with mount namespace activity in audit logs; no specific post-exploitation artifacts beyond crash dumps.

What your security team should do

  • Prioritize patching production Linux systems to the fixed kernel versions within maintenance windows
  • Monitor EPSS trend and any new exploit maturity reports for increased urgency
  • Apply defense-in-depth with seccomp and namespace isolation to limit local trigger surfaces
  • Schedule kernel updates across all affected Alpaquita and stable distributions

The record

In the Linux kernel, the following vulnerability has been resolved: fs/fhandle.c: fix a race in call of has_locked_children() may_decode_fh() is calling has_locked_children() while holding no locks. That's an oopsable race... The rest of the callers are safe since they are holding namespace_sem and are guaranteed a positive refcount on the mount in question. Rename the current has_locked_children() to __has_locked_children(), make it static and switch the fs/namespace.c users to it. Make has_locked_children() a wrapper for __has_locked_children(), calling the latter under read_seqlock_excl(&mount_lock).

Affected packages

Ecosystem Package Introduced Fixed
Debian:13 linux 0 No fix
Debian:13 linux 0 6.12.48-1
Debian:14 linux 0 6.16.3-1
Linux Kernel 6.11.0 6.12.46
openSUSE:Leap 16.0 dtb-aarch64 0 6.12.0-160000.6.1
openSUSE:Leap 16.0 kernel-64kb 0 6.12.0-160000.6.1
openSUSE:Leap 16.0 kernel-default 0 6.12.0-160000.6.1
openSUSE:Leap 16.0 kernel-default-base 0 6.12.0-160000.6.1.160000.2.4
openSUSE:Leap 16.0 kernel-docs 0 6.12.0-160000.6.1
openSUSE:Leap 16.0 kernel-kvmsmall 0 6.12.0-160000.6.1
openSUSE:Leap 16.0 kernel-obs-build 0 6.12.0-160000.6.1
openSUSE:Leap 16.0 kernel-obs-qa 0 6.12.0-160000.6.1
openSUSE:Leap 16.0 kernel-rt 0 6.12.0-160000.6.1
openSUSE:Leap 16.0 kernel-source 0 6.12.0-160000.6.1
openSUSE:Leap 16.0 kernel-syms 0 6.12.0-160000.6.1
openSUSE:Leap 16.0 kernel-zfcpdump 0 6.12.0-160000.6.1

Related vulnerabilities