Cloudanix VulnDB

CVE-2025-38615

High · 7.8

CVSS

7.8

EPSS

0.2%

Published

Aug 19, 2025

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A flaw in how Linux handles certain damaged file systems can cause crashes or data problems during everyday file operations.

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

What it actually does

Calling make_bad_inode() on a live inode already present in the icache and attached to a dentry in the ntfs3 driver evicts the inode or leaves dangling references, resulting in memory corruption or inconsistent filesystem state.

Why it matters to the business

Organizations running Linux systems that mount ntfs3 filesystems face elevated risk of kernel panics, file system corruption, and service disruption, particularly where ntfs3 volumes are used for data exchange or containers; the large number of downstream package dependents amplifies exposure.

How an attack unfolds

An attacker supplies or crafts a ntfs3 volume containing a file with a corrupted i_link field, mounts it, and performs a rename operation; the kernel then invokes make_bad_inode() on an inode that is already live and referenced, triggering the corruption path.

How to fix it

Upgrade the Linux kernel to commit b35a50d639ca5259466ef5fea85529bb4fb17d5b or later. For Chainguard packages, update openjdk-17-openj9 and related variants to 0.53.0-r0 or newer.

How to confirm the fix worked

Confirm the running kernel contains commit b35a50d639ca5259466ef5fea85529bb4fb17d5b; reproduce the original rename scenario on a corrupted ntfs3 image and verify that live inodes are no longer marked bad.

Typical attack path

  1. Mount a specially crafted or corrupted ntfs3 filesystem
  2. Locate or create a file whose i_link field is invalid
  3. Issue a rename syscall on that file
  4. Trigger make_bad_inode() on the still-live inode
  5. Observe resulting cache eviction or memory corruption

How to detect it

Inspect kernel logs for make_bad_inode calls during ntfs3 rename operations, unexpected inode cache evictions, or dentry/inode reference warnings; correlate with mount events of ntfs3 volumes.

What your security team should do

  • Prioritize kernel updates on all systems that mount ntfs3 volumes
  • Scan container images and host kernels for the listed Chainguard package versions
  • Add ntfs3 rename and make_bad_inode paths to crash and anomaly monitoring
  • Review ntfs3 usage and migrate high-value workloads to ext4 or xfs where feasible

The record

In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: cancle set bad inode after removing name fails The reproducer uses a file0 on a ntfs3 file system with a corrupted i_link. When renaming, the file0's inode is marked as a bad inode because the file name cannot be deleted. The underlying bug is that make_bad_inode() is called on a live inode. In some cases it's "icache lookup finds a normal inode, d_splice_alias() is called to attach it to dentry, while another thread decides to call make_bad_inode() on it - that would evict it from icache, but we'd already found it there earlier". In some it's outright "we have an inode attached to dentry - that's how we got it in the first place; let's call make_bad_inode() on it just for shits and giggles".

Affected packages

Ecosystem Package Introduced Fixed
Debian:12 linux 0 No fix
Debian:13 linux 0 No fix
Debian:14 linux 0 No fix
Debian:14 linux 0 6.16.3-1
Linux Kernel 5.15.0 6.6.102
Mageia:9 kernel 0 6.6.105-1.mga9
Mageia:9 kernel-linus 0 6.6.105-1.mga9
Mageia:9 kmod-virtualbox 0 7.1.10-10.mga9
Mageia:9 kmod-xtables-addons 0 3.24-86.mga9
Mageia:9 mageia-repos 0 9-4.mga9
Mageia:9 meta-task 0 9-4.mga9

Related vulnerabilities