GHSA-RQQP-4VHV-FQRG

Vulnerability from github – Published: 2024-07-29 15:30 – Updated: 2025-11-04 00:31
VLAI
Details

In 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().

Show details on source website

{
  "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"
    }
  ]
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

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.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…