CVE-2025-21896: Vulnerability in Linux Linux
In the Linux kernel, the following vulnerability has been resolved: fuse: revert back to __readahead_folio() for readahead In commit 3eab9d7bc2f4 ("fuse: convert readahead to use folios"), the logic was converted to using the new folio readahead code, which drops the reference on the folio once it is locked, using an inferred reference on the folio. Previously we held a reference on the folio for the entire duration of the readpages call. This is fine, however for the case for splice pipe responses where we will remove the old folio and splice in the new folio (see fuse_try_move_page()), we assume that there is a reference held on the folio for ap->folios, which is no longer the case. To fix this, revert back to __readahead_folio() which allows us to hold the reference on the folio for the duration of readpages until either we drop the reference ourselves in fuse_readpages_end() or the reference is dropped after it's replaced in the page cache in the splice case. This will fix the UAF bug that was reported.
AI Analysis
Technical Summary
CVE-2025-21896 is a use-after-free (UAF) vulnerability in the Linux kernel's FUSE (Filesystem in Userspace) implementation, specifically related to the readahead mechanism. The vulnerability originated from a code change in commit 3eab9d7bc2f4, which converted the readahead logic to use folios, a newer memory management abstraction. This change dropped the explicit reference count on folios once they were locked, relying instead on an inferred reference. Previously, the code held a reference on the folio for the entire duration of the readpages call, ensuring the folio was not freed prematurely. The issue arises in the splice pipe response path, where the old folio is removed and replaced with a new folio (via fuse_try_move_page()). The code incorrectly assumes that a reference is still held on the folio in ap->folios, but since the reference was dropped earlier, this leads to a use-after-free condition. This can cause memory corruption, kernel crashes, or potentially allow an attacker to execute arbitrary code in kernel space. The fix involved reverting to the older __readahead_folio() method, which maintains the reference on the folio for the duration of the readpages call until it is explicitly dropped, thereby preventing the UAF. This vulnerability affects Linux kernel versions containing the problematic commit and is relevant to systems using FUSE filesystems. No known exploits are currently reported in the wild, and no CVSS score has been assigned yet.
Potential Impact
For European organizations, this vulnerability poses a significant risk especially for those relying on Linux-based systems with FUSE filesystems, which are common in enterprise environments for mounting user-space filesystems, network filesystems, or virtual filesystems. Exploitation could lead to kernel crashes causing denial of service, or in worst cases, privilege escalation allowing attackers to gain root-level access. This could compromise confidentiality, integrity, and availability of critical systems. Given the widespread use of Linux servers in European data centers, cloud providers, and critical infrastructure, the impact could be severe if exploited. Organizations running containerized workloads or cloud-native applications on Linux hosts using FUSE are particularly at risk. The absence of known exploits suggests a window of opportunity to patch before active exploitation occurs, but the complexity of kernel vulnerabilities means exploitation could be targeted and stealthy.
Mitigation Recommendations
European organizations should prioritize applying the patch that reverts the readahead logic to __readahead_folio(), ensuring the reference counting on folios is correctly maintained. Since the vulnerability is in the Linux kernel, updating to the latest stable kernel version that includes this fix is critical. For environments where immediate kernel upgrades are challenging, consider isolating or limiting the use of FUSE filesystems, especially untrusted or external mounts. Employ kernel hardening techniques such as Kernel Address Space Layout Randomization (KASLR), Kernel Page Table Isolation (KPTI), and enable security modules like SELinux or AppArmor to reduce exploitation risk. Monitoring kernel logs for unusual crashes or anomalies related to FUSE operations can provide early detection. Additionally, review and restrict user permissions to mount or interact with FUSE filesystems to trusted users only. Coordination with Linux distribution vendors for timely patch deployment is essential.
Affected Countries
Germany, France, United Kingdom, Netherlands, Sweden, Finland, Italy, Spain, Poland, Belgium
CVE-2025-21896: Vulnerability in Linux Linux
Description
In the Linux kernel, the following vulnerability has been resolved: fuse: revert back to __readahead_folio() for readahead In commit 3eab9d7bc2f4 ("fuse: convert readahead to use folios"), the logic was converted to using the new folio readahead code, which drops the reference on the folio once it is locked, using an inferred reference on the folio. Previously we held a reference on the folio for the entire duration of the readpages call. This is fine, however for the case for splice pipe responses where we will remove the old folio and splice in the new folio (see fuse_try_move_page()), we assume that there is a reference held on the folio for ap->folios, which is no longer the case. To fix this, revert back to __readahead_folio() which allows us to hold the reference on the folio for the duration of readpages until either we drop the reference ourselves in fuse_readpages_end() or the reference is dropped after it's replaced in the page cache in the splice case. This will fix the UAF bug that was reported.
AI-Powered Analysis
Technical Analysis
CVE-2025-21896 is a use-after-free (UAF) vulnerability in the Linux kernel's FUSE (Filesystem in Userspace) implementation, specifically related to the readahead mechanism. The vulnerability originated from a code change in commit 3eab9d7bc2f4, which converted the readahead logic to use folios, a newer memory management abstraction. This change dropped the explicit reference count on folios once they were locked, relying instead on an inferred reference. Previously, the code held a reference on the folio for the entire duration of the readpages call, ensuring the folio was not freed prematurely. The issue arises in the splice pipe response path, where the old folio is removed and replaced with a new folio (via fuse_try_move_page()). The code incorrectly assumes that a reference is still held on the folio in ap->folios, but since the reference was dropped earlier, this leads to a use-after-free condition. This can cause memory corruption, kernel crashes, or potentially allow an attacker to execute arbitrary code in kernel space. The fix involved reverting to the older __readahead_folio() method, which maintains the reference on the folio for the duration of the readpages call until it is explicitly dropped, thereby preventing the UAF. This vulnerability affects Linux kernel versions containing the problematic commit and is relevant to systems using FUSE filesystems. No known exploits are currently reported in the wild, and no CVSS score has been assigned yet.
Potential Impact
For European organizations, this vulnerability poses a significant risk especially for those relying on Linux-based systems with FUSE filesystems, which are common in enterprise environments for mounting user-space filesystems, network filesystems, or virtual filesystems. Exploitation could lead to kernel crashes causing denial of service, or in worst cases, privilege escalation allowing attackers to gain root-level access. This could compromise confidentiality, integrity, and availability of critical systems. Given the widespread use of Linux servers in European data centers, cloud providers, and critical infrastructure, the impact could be severe if exploited. Organizations running containerized workloads or cloud-native applications on Linux hosts using FUSE are particularly at risk. The absence of known exploits suggests a window of opportunity to patch before active exploitation occurs, but the complexity of kernel vulnerabilities means exploitation could be targeted and stealthy.
Mitigation Recommendations
European organizations should prioritize applying the patch that reverts the readahead logic to __readahead_folio(), ensuring the reference counting on folios is correctly maintained. Since the vulnerability is in the Linux kernel, updating to the latest stable kernel version that includes this fix is critical. For environments where immediate kernel upgrades are challenging, consider isolating or limiting the use of FUSE filesystems, especially untrusted or external mounts. Employ kernel hardening techniques such as Kernel Address Space Layout Randomization (KASLR), Kernel Page Table Isolation (KPTI), and enable security modules like SELinux or AppArmor to reduce exploitation risk. Monitoring kernel logs for unusual crashes or anomalies related to FUSE operations can provide early detection. Additionally, review and restrict user permissions to mount or interact with FUSE filesystems to trusted users only. Coordination with Linux distribution vendors for timely patch deployment is essential.
For access to advanced analysis and higher rate limits, contact root@offseq.com
Technical Details
- Data Version
- 5.1
- Assigner Short Name
- Linux
- Date Reserved
- 2024-12-29T08:45:45.783Z
- Cisa Enriched
- false
- Cvss Version
- null
- State
- PUBLISHED
Threat ID: 682d9833c4522896dcbe8b3f
Added to database: 5/21/2025, 9:09:07 AM
Last enriched: 6/30/2025, 10:26:35 AM
Last updated: 8/3/2025, 4:23:03 PM
Views: 16
Related Threats
Researcher to release exploit for full auth bypass on FortiWeb
HighCVE-2025-9091: Hard-coded Credentials in Tenda AC20
LowCVE-2025-9090: Command Injection in Tenda AC20
MediumCVE-2025-9092: CWE-400 Uncontrolled Resource Consumption in Legion of the Bouncy Castle Inc. Bouncy Castle for Java - BC-FJA 2.1.0
LowCVE-2025-9089: Stack-based Buffer Overflow in Tenda AC20
HighActions
Updates to AI analysis are available only with a Pro account. Contact root@offseq.com for access.
External Links
Need enhanced features?
Contact root@offseq.com for Pro access with improved analysis and higher rate limits.