)]}'
{
  "commit": "cc42da35e19eef3464627a45ce8490cebee3318c",
  "tree": "547ecd024d237d19df8be4aadfcb447137a8fae8",
  "parents": [
    "45ed56f1b6dc5501e2b933922d17ced9d9e44d79"
  ],
  "author": {
    "name": "Baokun Li",
    "email": "libaokun1@huawei.com",
    "time": "Fri Jul 19 21:43:38 2024 +0800"
  },
  "committer": {
    "name": "Michael Kochera",
    "email": "kochera@google.com",
    "time": "Fri Sep 06 01:17:28 2024 +0000"
  },
  "message": "cachefiles: fix slab-use-after-free in cachefiles_withdraw_cookie()\n\n[ Upstream commit 5d8f805789072ea7fd39504694b7bd17e5f751c4 ]\n\nWe got the following issue in our fault injection stress test:\n\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\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\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\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) \u003d\u003d 0\n                              fscache_perform_lookup\n                               cachefiles_lookup_cookie\n                                cachefiles_alloc_object\n                                 refcount_set(\u0026object-\u003eref, 1);\n                                 object-\u003evolume \u003d 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 \u003d 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 \u003d\u003d 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().\n\nBUG\u003db/362700590\nTEST\u003dNone\nRELEASE_NOTE\u003dFix CVE-2024-41057 in the linux kernel.\n\ncos-patch: security-high\nFixes: fe2140e2f57f (\"cachefiles: Implement volume support\")\nSuggested-by: Hou Tao \u003choutao1@huawei.com\u003e\nSigned-off-by: Baokun Li \u003clibaokun1@huawei.com\u003e\nLink: https://lore.kernel.org/r/20240628062930.2467993-4-libaokun@huaweicloud.com\nSigned-off-by: Christian Brauner \u003cbrauner@kernel.org\u003e\nSigned-off-by: Baokun Li \u003clibaokun1@huawei.com\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\nChange-Id: Ieb16f423df7295bb0f64a30abbad697dcbcb23af\nReviewed-on: https://cos-review.googlesource.com/c/third_party/kernel/+/80202\nTested-by: Cusky Presubmit Bot \u003cpresubmit@cos-infra-prod.iam.gserviceaccount.com\u003e\nReviewed-by: Oleksandr Tymoshenko \u003covt@google.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "56ef519a36a09d4697e92db9e6a057613c110939",
      "old_mode": 33188,
      "old_path": "fs/cachefiles/cache.c",
      "new_id": "9fb06dc165202cbc86d690b51a9e7354fe8fc56e",
      "new_mode": 33188,
      "new_path": "fs/cachefiles/cache.c"
    },
    {
      "type": "modify",
      "old_id": "89df0ba8ba5e7ba74acc538a5951cf91a833a606",
      "old_mode": 33188,
      "old_path": "fs/cachefiles/volume.c",
      "new_id": "781aac4ef274bdf5459e073de762c045f13f9112",
      "new_mode": 33188,
      "new_path": "fs/cachefiles/volume.c"
    }
  ]
}