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

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

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

================================================================== BUG: KASAN: slab-use-after-free in cachefiles_ondemand_daemon_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: kasan_report+0x93/0xc0 cachefiles_ondemand_daemon_read+0xb41/0xb60 vfs_read+0x169/0xb50 ksys_read+0xf5/0x1e0

Allocated by task 116: kmem_cache_alloc+0x140/0x3a0 cachefiles_lookup_cookie+0x140/0xcd0 fscache_cookie_state_machine+0x43c/0x1230 […]

Freed by task 792: kmem_cache_free+0xfe/0x390 cachefiles_put_object+0x241/0x480 fscache_cookie_state_machine+0x5c8/0x1230 […]

Following is the process that triggers the issue:

 mount  |   daemon_thread1    |    daemon_thread2

cachefiles_withdraw_cookie cachefiles_ondemand_clean_object(object) cachefiles_ondemand_send_req REQ_A = kzalloc(sizeof(*req) + data_len) wait_for_completion(&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

cachefiles_put_object kmem_cache_free(cachefiles_object_jar, object) REQ_A->object->ondemand->ondemand_id // object UAF !!!

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

Weakness

The product reuses or references memory after it has been freed. At some point afterward, the memory may be allocated again and saved in another pointer, while the original pointer references a location somewhere within the new allocation. Any operations using the original pointer are no longer valid because the memory “belongs” to the code that operates on the new pointer.

Affected Software

Potential Mitigations

References

• https://git.kernel.org/stable/c/3958679c49152391209b32be3357193300a51abd
• https://git.kernel.org/stable/c/93064676a2820420a2d37d7c8289f277fe20793d
• https://git.kernel.org/stable/c/cb55625f8eb9d2de8be4da0c4580d48cbb32058e
• https://git.kernel.org/stable/c/da4a827416066191aafeeccee50a8836a826ba10
• https://git.kernel.org/stable/c/3958679c49152391209b32be3357193300a51abd
• https://git.kernel.org/stable/c/93064676a2820420a2d37d7c8289f277fe20793d
• https://git.kernel.org/stable/c/cb55625f8eb9d2de8be4da0c4580d48cbb32058e
• https://git.kernel.org/stable/c/da4a827416066191aafeeccee50a8836a826ba10
• https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html