CVE-2025-71074: functionfs: fix the open/removal races
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.
Security readout for executives and security teams
Plain-English summary
A local user can trigger a race while Linux FunctionFS endpoint files are being opened and removed. A successful race leaves the kernel using freed memory during later reads or writes, potentially enabling data exposure, corruption, or system compromise. The supplied CVSS score is 7.8, but exposure depends on FunctionFS use and local access.
Executive priority
Prioritize affected multi-user, appliance, or embedded systems where untrusted users can access FunctionFS. Treat remediation as high priority because successful exploitation may compromise the kernel, but avoid assuming fleet-wide exposure until FunctionFS usage and vendor patch status are verified.
Technical view
ffs_epfile_open() may race with dynamic-file removal before the open-file count is incremented, leaving file->private_data referencing freed memory. Subsequent read or write operations can cause a use-after-free. The kernel fix serializes opens, prevents count resurrection, marks removed inodes, and verifies inode presence and FFS_ACTIVE state.
Likely exposure
Potentially exposed systems run an affected Linux kernel, use FunctionFS, and permit a low-privileged local user to interact with relevant endpoint files. The supplied version data identifies Linux 2.6.35 through 6.19 as affected, but downstream vendor backports may change actual status.
Exploitation context
The CVSS vector describes local, low-complexity exploitation requiring low privileges and no user interaction, with potentially high confidentiality, integrity, and availability impact. The CVE is not listed as KEV in the supplied bundle, and no cited source establishes active exploitation or public weaponization.
Researcher notes
The flaw is an open-versus-removal lifetime race involving ffs->opened, dynamic inode removal, and file->private_data. The source describes a deterministic correction strategy but provides no exploitation evidence. The supplied affected-version range is broad and should be reconciled against stable-tree and distribution backport records.
Mitigation direction
Identify systems using FunctionFS and prioritize those accessible to untrusted local users.
Apply a vendor-supported kernel containing the referenced FunctionFS race fix.
Check distribution advisories because kernel fixes may be backported without matching upstream version numbers.
Restrict unnecessary local access to FunctionFS endpoint files while updates are pending.
Validation and detection
Record running kernel versions and compare them with vendor security advisories.
Confirm whether FunctionFS is enabled and actively used on each system.
Verify the installed kernel includes the referenced upstream fix or an equivalent vendor backport.
Reassess local permissions protecting FunctionFS endpoint files after remediation.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2025-71074 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
1CVSS vectors
3Timeline events
0ADP providers
2Source links
CVSS vector scores
1 official score
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.