CVE-2024-41051: cachefiles: wait for ondemand_object_worker to finish when dropping object
In the Linux kernel, the following vulnerability has been resolved:
cachefiles: wait for ondemand_object_worker to finish when dropping object
When queuing ondemand_object_worker() to re-open the object,
cachefiles_object is not pinned. The cachefiles_object may be freed when
the pending read request is completed intentionally and the related
erofs is umounted. If ondemand_object_worker() runs after the object is
freed, it will incur use-after-free problem as shown below.
process A processs B process C process D
cachefiles_ondemand_send_req()
// send a read req X
// wait for its completion
// close ondemand fd
cachefiles_ondemand_fd_release()
// set object as CLOSE
cachefiles_ondemand_daemon_read()
// set object as REOPENING
queue_work(fscache_wq, &info->ondemand_work)
// close /dev/cachefiles
cachefiles_daemon_release
cachefiles_flush_reqs
complete(&req->done)
// read req X is completed
// umount the erofs fs
cachefiles_put_object()
// object will be freed
cachefiles_ondemand_deinit_obj_info()
kmem_cache_free(object)
// both info and object are freed
ondemand_object_worker()
When dropping an object, it is no longer necessary to reopen the object,
so use cancel_work_sync() to cancel or wait for ondemand_object_worker()
to finish.
Security readout for executives and security teams
Plain-English summary
This is a Linux kernel use-after-free in cachefiles on-demand handling. Under a specific race involving pending reads, object reopening, daemon closure, and filesystem unmount, kernel memory for a cache object can be freed before queued work finishes. Public sources show a kernel fix, but provide no CVSS score or confirmed exploitation.
Executive priority
Treat as a kernel maintenance item with environment-specific urgency. Prioritize patching on systems using cachefiles-related functionality, but avoid emergency escalation unless your vendor indicates exploitability or affected services are exposed in your estate.
Technical view
The flaw occurs because ondemand_object_worker() may be queued without pinning cachefiles_object. If the related read completes and erofs is unmounted, cachefiles_put_object() can free the object before the worker runs. The fix cancels or waits for the worker with cancel_work_sync() when dropping the object.
Likely exposure
Exposure appears limited to Linux systems using cachefiles on-demand behavior, with source evidence referencing erofs and /dev/cachefiles. Assess kernels in the affected Linux version ranges and distribution backports. Systems not using these kernel features may have lower practical exposure, but source evidence is incomplete.
Exploitation context
The source bundle does not show KEV listing, public exploitation, weaponized proof of concept, or attacker prerequisites. The described condition is a race in kernel cachefiles lifecycle handling, so practical exploitation depends on local configuration and reachable cachefiles/erofs workflows.
Researcher notes
Evidence supports a lifecycle race leading to use-after-free in Linux cachefiles. The bundle names stable commits and Debian LTS notice, but no CWE, CVSS, exploit status, or complete operational impact. Validate against kernel source or vendor package changelogs.
Mitigation direction
Update to a kernel containing the referenced stable fixes or distribution backports.
Review Debian LTS guidance if running affected Debian kernel packages.
Check vendor advisories for exact fixed package versions in your distribution.
Prioritize hosts using cachefiles, fscache, erofs, or /dev/cachefiles workflows.
Validation and detection
Inventory Linux kernel versions across servers and appliances.
Check whether cachefiles or related on-demand cache services are enabled.
Map deployed kernels against vendor fixed versions and backported patches.
Confirm patched kernels include the cancel_work_sync() fix for object teardown.
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-41051 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.