Linux Kernel up to 6.18.2 ffs_epfile_open deserialization

Summaryinfo

A vulnerability classified as critical has been found in Linux Kernel up to 6.18.2. This issue affects the function ffs_epfile_open. The manipulation leads to deserialization. This vulnerability is traded as CVE-2025-71074. There is no exploit available. It is recommended to upgrade the affected component.

Detailsinfo

A vulnerability was found in Linux Kernel up to 6.18.2 and classified as critical. This issue affects the function ffs_epfile_open. The manipulation with an unknown input leads to a deserialization vulnerability. Using CWE to declare the problem leads to CWE-502. The product deserializes untrusted data without sufficiently verifying that the resulting data will be valid. The impact remains unknown. The summary by CVE is:

In the Linux kernel, the following vulnerability has been resolved: functionfs: fix the open/removal races ffs_epfile_open() can race with removal, ending up with file->private_data pointing to freed object. There is a total count of opened files on functionfs (both ep0 and dynamic ones) and when it hits zero, dynamic files get removed. Unfortunately, that removal can happen while another thread is in ffs_epfile_open(), but has not incremented the count yet. In that case open will succeed, leaving us with UAF on any subsequent read() or write(). The root cause is that ffs->opened is misused; atomic_dec_and_test() vs. atomic_add_return() is not a good idea, when object remains visible all along. To untangle that * serialize openers on ffs->mutex (both for ep0 and for dynamic files) * have dynamic ones use atomic_inc_not_zero() and fail if we had zero ->opened; in that case the file we are opening is doomed. * have the inodes of dynamic files marked on removal (from the callback of simple_recursive_removal()) - clear ->i_private there. * have open of dynamic ones verify they hadn't been already removed, along with checking that state is FFS_ACTIVE.

It is possible to read the advisory at git.kernel.org. The identification of this vulnerability is CVE-2025-71074 since 01/13/2026. The exploitation is known to be difficult. Technical details of the vulnerability are known, but there is no available exploit. The pricing for an exploit might be around USD $0-$5k at the moment (estimation calculated on 03/31/2026).

Upgrading to version 6.18.3 or 6.19-rc1 eliminates this vulnerability. Applying the patch b49c766856fb5901490de577e046149ebf15e39d/e5bf5ee266633cb18fff6f98f0b7d59a62819eee 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.

Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Productinfo

Type

• Operating System

Vendor

• Linux

Name

• Kernel

Version

• 6.18.0
• 6.18.1
• 6.18.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

Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Discussion