In the Linux kernel, the following vulnerability has been resolved:

cachefiles: fix slab-use-after-free in cachefilesondemanddaemon_read()

We got the following issue in a fuzz test of randomly issuing the restore command:

================================================================== BUG: KASAN: slab-use-after-free in cachefilesondemanddaemon_read+0xb41/0xb60 Read of size 8 at addr ffff888122e84088 by task ondemand-04-dae/963

CPU: 13 PID: 963 Comm: ondemand-04-dae Not tainted 6.8.0-dirty #564 Call Trace: kasanreport+0x93/0xc0 cachefilesondemanddaemonread+0xb41/0xb60 vfsread+0x169/0xb50 ksysread+0xf5/0x1e0

Allocated by task 116: kmemcachealloc+0x140/0x3a0 cachefileslookupcookie+0x140/0xcd0 fscachecookiestate_machine+0x43c/0x1230 [...]

Freed by task 792: kmemcachefree+0xfe/0x390 cachefilesputobject+0x241/0x480 fscachecookiestate_machine+0x5c8/0x1230

[...]

Following is the process that triggers the issue:

mount | daemonthread1 | daemonthread2

cachefileswithdrawcookie cachefilesondemandcleanobject(object) cachefilesondemandsendreq REQA = kzalloc(sizeof(*req) + datalen) waitforcompletion(&REQ_A->done)

        cachefiles_daemon_read
         cachefiles_ondemand_daemon_read
          REQ_A = cachefiles_ondemand_select_req
          msg->object_id = req->object->ondemand->ondemand_id
                              ------ restore ------
                              cachefiles_ondemand_restore
                              xas_for_each(&xas, req, ULONG_MAX)
                               xas_set_mark(&xas, CACHEFILES_REQ_NEW)

                              cachefiles_daemon_read
                               cachefiles_ondemand_daemon_read
                                REQ_A = cachefiles_ondemand_select_req
          copy_to_user(_buffer, msg, n)
           xa_erase(&cache->reqs, id)
           complete(&REQ_A->done)
          ------ close(fd) ------
          cachefiles_ondemand_fd_release
           cachefiles_put_object

cachefilesputobject kmemcachefree(cachefilesobjectjar, object) REQA->object->ondemand->ondemandid // object UAF !!!

When we see the request within xalock, req->object must not have been freed yet, so grab the reference count of object before xaunlock to avoid the above issue.