Linux Kernel up to 6.6.111/6.12.52/6.17.2 ntfs3 rename BITMAP allocation of resources

Summaryinfo

A vulnerability was found in Linux Kernel up to 6.6.111/6.12.52/6.17.2. It has been rated as critical. Affected by this vulnerability is the function rename of the component ntfs3. This manipulation of the argument BITMAP causes allocation of resources. This vulnerability appears as CVE-2025-40067. There is no available exploit. Upgrading the affected component is advised.

Detailsinfo

A vulnerability was found in Linux Kernel up to 6.6.111/6.12.52/6.17.2. It has been declared as critical. Affected by this vulnerability is the function rename of the component ntfs3. The manipulation of the argument BITMAP with an unknown input leads to a allocation of resources vulnerability. The CWE definition for the vulnerability is CWE-770. The product allocates a reusable resource or group of resources on behalf of an actor without imposing any restrictions on the size or number of resources that can be allocated, in violation of the intended security policy for that actor. The impact remains unknown. The summary by CVE is:

In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: reject index allocation if $BITMAP is empty but blocks exist Index allocation requires at least one bit in the $BITMAP attribute to track usage of index entries. If the bitmap is empty while index blocks are already present, this reflects on-disk corruption. syzbot triggered this condition using a malformed NTFS image. During a rename() operation involving a long filename (which spans multiple index entries), the empty bitmap allowed the name to be added without valid tracking. Subsequent deletion of the original entry failed with -ENOENT, due to unexpected index state. Reject such cases by verifying that the bitmap is not empty when index blocks exist.

The advisory is shared at git.kernel.org. This vulnerability is known as CVE-2025-40067 since 04/16/2025. Technical details are known, but no exploit is available.

The vulnerability scanner Nessus provides a plugin with the ID 271904 (Linux Distros Unpatched Vulnerability : CVE-2025-40067), which helps to determine the existence of the flaw in a target environment.

Upgrading to version 6.6.112, 6.12.53, 6.17.3 or 6.18-rc1 eliminates this vulnerability. Applying the patch 978aac54e93ea35aab20b32ae393d3d33964e7ae/be66551da203862c689c12e1d35ce87217c017c1/039ddf353cc33f6546a87ec1ac3210637d714bec/0dc7117da8f92dd5fe077d712a756eccbe377d40 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.

The vulnerability is also documented in the databases at Tenable (271904) and CERT Bund (WID-SEC-2025-2431). If you want to get the best quality for vulnerability data then you always have to consider VulDB.

Affected

• Google Container-Optimized OS
• Debian Linux
• Amazon Linux 2
• Red Hat Enterprise Linux
• Ubuntu Linux
• SUSE Linux
• Oracle Linux
• SUSE openSUSE
• Open Source Linux Kernel
• RESF Rocky Linux
• Microsoft Azure
• Dell NetWorker

Productinfo

Type

• Operating System

Vendor

• Linux

Name

• Kernel

Version

• 6.6.111
• 6.12.0
• 6.12.1
• 6.12.2
• 6.12.3
• 6.12.4
• 6.12.5
• 6.12.6
• 6.12.7
• 6.12.8
• 6.12.9
• 6.12.10
• 6.12.11
• 6.12.12
• 6.12.13
• 6.12.14
• 6.12.15
• 6.12.16
• 6.12.17
• 6.12.18
• 6.12.19
• 6.12.20
• 6.12.21
• 6.12.22
• 6.12.23
• 6.12.24
• 6.12.25
• 6.12.26
• 6.12.27
• 6.12.28
• 6.12.29
• 6.12.30
• 6.12.31
• 6.12.32
• 6.12.33
• 6.12.34
• 6.12.35
• 6.12.36
• 6.12.37
• 6.12.38
• 6.12.39
• 6.12.40
• 6.12.41
• 6.12.42
• 6.12.43
• 6.12.44
• 6.12.45
• 6.12.46
• 6.12.47
• 6.12.48
• 6.12.49
• 6.12.50
• 6.12.51
• 6.12.52
• 6.17.0
• 6.17.1
• 6.17.2

License

• open-source

Website

• Vendor: https://www.kernel.org/

CPE 2.3info

• 🔒
• 🔒
• 🔒

CPE 2.2info

• 🔒
• 🔒
• 🔒

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

If you want to get the best quality for vulnerability data then you always have to consider VulDB.

Discussion