GHSA-RQQP-4VHV-FQRG
Vulnerability from github – Published: 2024-07-29 15:30 – Updated: 2025-11-04 00:31In the Linux kernel, the following vulnerability has been resolved:
cachefiles: fix slab-use-after-free in cachefiles_withdraw_cookie()
We got the following issue in our fault injection stress test:
================================================================== BUG: KASAN: slab-use-after-free in cachefiles_withdraw_cookie+0x4d9/0x600 Read of size 8 at addr ffff888118efc000 by task kworker/u78:0/109
CPU: 13 PID: 109 Comm: kworker/u78:0 Not tainted 6.8.0-dirty #566 Call Trace: kasan_report+0x93/0xc0 cachefiles_withdraw_cookie+0x4d9/0x600 fscache_cookie_state_machine+0x5c8/0x1230 fscache_cookie_worker+0x91/0x1c0 process_one_work+0x7fa/0x1800 [...]
Allocated by task 117: kmalloc_trace+0x1b3/0x3c0 cachefiles_acquire_volume+0xf3/0x9c0 fscache_create_volume_work+0x97/0x150 process_one_work+0x7fa/0x1800 [...]
Freed by task 120301: kfree+0xf1/0x2c0 cachefiles_withdraw_cache+0x3fa/0x920 cachefiles_put_unbind_pincount+0x1f6/0x250 cachefiles_daemon_release+0x13b/0x290 __fput+0x204/0xa00 task_work_run+0x139/0x230 do_exit+0x87a/0x29b0 [...] ==================================================================
Following is the process that triggers the issue:
p1 | p2
fscache_begin_lookup
fscache_begin_volume_access
fscache_cache_is_live(fscache_cache)
cachefiles_daemon_release cachefiles_put_unbind_pincount cachefiles_daemon_unbind cachefiles_withdraw_cache fscache_withdraw_cache fscache_set_cache_state(cache, FSCACHE_CACHE_IS_WITHDRAWN); cachefiles_withdraw_objects(cache) fscache_wait_for_objects(fscache) atomic_read(&fscache_cache->object_count) == 0 fscache_perform_lookup cachefiles_lookup_cookie cachefiles_alloc_object refcount_set(&object->ref, 1); object->volume = volume fscache_count_object(vcookie->cache); atomic_inc(&fscache_cache->object_count) cachefiles_withdraw_volumes cachefiles_withdraw_volume fscache_withdraw_volume __cachefiles_free_volume kfree(cachefiles_volume) fscache_cookie_state_machine cachefiles_withdraw_cookie cache = object->volume->cache; // cachefiles_volume UAF !!!
After setting FSCACHE_CACHE_IS_WITHDRAWN, wait for all the cookie lookups to complete first, and then wait for fscache_cache->object_count == 0 to avoid the cookie exiting after the volume has been freed and triggering the above issue. Therefore call fscache_withdraw_volume() before calling cachefiles_withdraw_objects().
This way, after setting FSCACHE_CACHE_IS_WITHDRAWN, only the following two cases will occur: 1) fscache_begin_lookup fails in fscache_begin_volume_access(). 2) fscache_withdraw_volume() will ensure that fscache_count_object() has been executed before calling fscache_wait_for_objects().
{
"affected": [],
"aliases": [
"CVE-2024-41057"
],
"database_specific": {
"cwe_ids": [
"CWE-416"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-07-29T15:15:13Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ncachefiles: fix slab-use-after-free in cachefiles_withdraw_cookie()\n\nWe got the following issue in our fault injection stress test:\n\n==================================================================\nBUG: KASAN: slab-use-after-free in cachefiles_withdraw_cookie+0x4d9/0x600\nRead of size 8 at addr ffff888118efc000 by task kworker/u78:0/109\n\nCPU: 13 PID: 109 Comm: kworker/u78:0 Not tainted 6.8.0-dirty #566\nCall Trace:\n \u003cTASK\u003e\n kasan_report+0x93/0xc0\n cachefiles_withdraw_cookie+0x4d9/0x600\n fscache_cookie_state_machine+0x5c8/0x1230\n fscache_cookie_worker+0x91/0x1c0\n process_one_work+0x7fa/0x1800\n [...]\n\nAllocated by task 117:\n kmalloc_trace+0x1b3/0x3c0\n cachefiles_acquire_volume+0xf3/0x9c0\n fscache_create_volume_work+0x97/0x150\n process_one_work+0x7fa/0x1800\n [...]\n\nFreed by task 120301:\n kfree+0xf1/0x2c0\n cachefiles_withdraw_cache+0x3fa/0x920\n cachefiles_put_unbind_pincount+0x1f6/0x250\n cachefiles_daemon_release+0x13b/0x290\n __fput+0x204/0xa00\n task_work_run+0x139/0x230\n do_exit+0x87a/0x29b0\n [...]\n==================================================================\n\nFollowing is the process that triggers the issue:\n\n p1 | p2\n------------------------------------------------------------\n fscache_begin_lookup\n fscache_begin_volume_access\n fscache_cache_is_live(fscache_cache)\ncachefiles_daemon_release\n cachefiles_put_unbind_pincount\n cachefiles_daemon_unbind\n cachefiles_withdraw_cache\n fscache_withdraw_cache\n fscache_set_cache_state(cache, FSCACHE_CACHE_IS_WITHDRAWN);\n cachefiles_withdraw_objects(cache)\n fscache_wait_for_objects(fscache)\n atomic_read(\u0026fscache_cache-\u003eobject_count) == 0\n fscache_perform_lookup\n cachefiles_lookup_cookie\n cachefiles_alloc_object\n refcount_set(\u0026object-\u003eref, 1);\n object-\u003evolume = volume\n fscache_count_object(vcookie-\u003ecache);\n atomic_inc(\u0026fscache_cache-\u003eobject_count)\n cachefiles_withdraw_volumes\n cachefiles_withdraw_volume\n fscache_withdraw_volume\n __cachefiles_free_volume\n kfree(cachefiles_volume)\n fscache_cookie_state_machine\n cachefiles_withdraw_cookie\n cache = object-\u003evolume-\u003ecache;\n // cachefiles_volume UAF !!!\n\nAfter setting FSCACHE_CACHE_IS_WITHDRAWN, wait for all the cookie lookups\nto complete first, and then wait for fscache_cache-\u003eobject_count == 0 to\navoid the cookie exiting after the volume has been freed and triggering\nthe above issue. Therefore call fscache_withdraw_volume() before calling\ncachefiles_withdraw_objects().\n\nThis way, after setting FSCACHE_CACHE_IS_WITHDRAWN, only the following two\ncases will occur:\n1) fscache_begin_lookup fails in fscache_begin_volume_access().\n2) fscache_withdraw_volume() will ensure that fscache_count_object() has\n been executed before calling fscache_wait_for_objects().",
"id": "GHSA-rqqp-4vhv-fqrg",
"modified": "2025-11-04T00:31:00Z",
"published": "2024-07-29T15:30:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41057"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5d8f805789072ea7fd39504694b7bd17e5f751c4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8de253177112a47c9af157d23ae934779188b4e1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9e67589a4a7b7e5660b524d1d5fe61242bcbcc11"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ef81340401e8a371d6b17f69e76d861920972cfe"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.