CVE-2025-40313

What it actually does

The flaw allowed ntfs3 $Extend metadata records to carry inode modes outside the set of types (S_IFDIR/S_IFLNK/S_IFREG/S_IFCHR/S_IFBLK/S_IFIFO/S_IFSOCK) required by may_open(), violating VFS inode-type assumptions.

Why it matters to the business

Systems mounting NTFS volumes could experience unexpected filesystem behavior or crashes when $Extend records are accessed, affecting stability of Linux workloads that rely on ntfs3.

How an attack unfolds

An attacker supplies a crafted NTFS image containing $Extend records with non-standard modes; when the image is mounted and the records are opened, may_open() rejects the inode type, leading to failure or kernel-level side effects.

How to fix it

Upgrade the Linux kernel to a version containing commit 63eb6730ce0604d3eacf036c2f68ea70b068317c (or later stable equivalent) so that $Extend records are explicitly treated as S_IFREG.

How to confirm the fix worked

Confirm the running kernel contains the referenced commit, then mount an NTFS volume and verify that $Extend directory entries report S_IFREG mode via stat or debugfs.

Typical attack path

1. Prepare a malicious NTFS filesystem image with non-conforming $Extend records
2. Cause the victim kernel to mount the image via ntfs3
3. Trigger open or access operations on the $Extend metadata
4. Observe denial-of-service or unexpected VFS behavior

How to detect it

Review kernel logs for ntfs3-related warnings or VFS may_open errors during NTFS mount or file-open events; correlate with recent attachment of external NTFS media.

What your security team should do

• Apply the kernel update containing commit 63eb6730ce0604d3eacf036c2f68ea70b068317c across all affected distributions
• Prioritize systems that routinely mount untrusted NTFS volumes
• Add ntfs3 mount operations to routine kernel-crash monitoring