CVE-2024-40900: cachefiles: remove requests from xarray during flushing requests
In the Linux kernel, the following vulnerability has been resolved:
cachefiles: remove requests from xarray during flushing requests
Even with CACHEFILES_DEAD set, we can still read the requests, so in the
following concurrency the request may be used after it has been freed:
mount | daemon_thread1 | daemon_thread2
------------------------------------------------------------
cachefiles_ondemand_init_object
cachefiles_ondemand_send_req
REQ_A = kzalloc(sizeof(*req) + data_len)
wait_for_completion(&REQ_A->done)
cachefiles_daemon_read
cachefiles_ondemand_daemon_read
// close dev fd
cachefiles_flush_reqs
complete(&REQ_A->done)
kfree(REQ_A)
xa_lock(&cache->reqs);
cachefiles_ondemand_select_req
req->msg.opcode != CACHEFILES_OP_READ
// req use-after-free !!!
xa_unlock(&cache->reqs);
xa_destroy(&cache->reqs)
Hence remove requests from cache->reqs when flushing them to avoid
accessing freed requests.
Security readout for executives and security teams
Plain-English summary
A race condition in the Linux kernel’s CacheFiles on-demand feature can leave one process using a request after another process frees it. An authenticated local user may be able to trigger serious memory corruption, potentially affecting confidentiality, integrity, or availability. Systems not using the affected CacheFiles functionality are less likely to be exposed.
Executive priority
Treat this as a high-priority kernel update for multi-user or otherwise locally accessible systems using CacheFiles on-demand. Broader emergency action is not supported by the supplied evidence because exploitation is local, feature-dependent, and not documented as active. Require asset owners to verify both feature use and vendor patch status.
Technical view
During request flushing, completed CacheFiles on-demand requests remained reachable in the cache request xarray. A concurrent daemon read could select a request after the waiting path freed it, causing a use-after-free. The upstream fix removes requests from the xarray while flushing. CVSS 3.1 is 7.8: local, low complexity, low privileges, no user interaction, with potentially high impact.
Likely exposure
Exposure requires an affected Linux kernel, use of CacheFiles on-demand functionality, and local low-privileged access. The supplied version data identifies affected releases including 5.19, 6.1.95, 6.6.35, 6.9.6, and 6.10, but distributors may backport fixes without changing upstream version numbers.
Exploitation context
The supplied record is not in CISA KEV and provides no evidence of active exploitation or public weaponization. Exploitation is locally initiated and depends on a specific concurrency condition involving CacheFiles request handling. Absence from KEV does not establish that exploitation is impossible or has never occurred.
Researcher notes
The defect is a concurrency-driven use-after-free: flushing completes requests but previously left them indexed until xarray destruction, allowing selection after deallocation. The fix changes lifecycle ordering by removing requests during flushing. The bundle does not establish a reliable exploitation primitive, affected distribution package matrix, observed attacks, or specific compromise indicators.
Mitigation direction
Install a vendor-supported kernel containing the referenced CacheFiles fix, then reboot into it.
Check distributor advisories because patched package versions may differ from upstream kernel versions.
Prioritize systems using CacheFiles on-demand and permitting untrusted or low-privileged local users.
If updates are delayed, obtain supported interim mitigation guidance from the operating-system vendor.
Validation and detection
Inventory running kernel versions and identify systems using CacheFiles on-demand functionality.
Confirm the installed kernel package includes the fix or an equivalent vendor backport.
Reboot updated systems and verify the running kernel matches the patched package.
Review kernel logs for unexplained CacheFiles faults, memory corruption, or crashes without treating them as proof of exploitation.
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-2024-40900 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.
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.