CVE-2024-41058

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cachefiles: fix slab-use-after-free in fscache_withdraw_volume()<br /> <br /> We got the following issue in our fault injection stress test:<br /> <br /> ==================================================================<br /> BUG: KASAN: slab-use-after-free in fscache_withdraw_volume+0x2e1/0x370<br /> Read of size 4 at addr ffff88810680be08 by task ondemand-04-dae/5798<br /> <br /> CPU: 0 PID: 5798 Comm: ondemand-04-dae Not tainted 6.8.0-dirty #565<br /> Call Trace:<br /> kasan_check_range+0xf6/0x1b0<br /> fscache_withdraw_volume+0x2e1/0x370<br /> cachefiles_withdraw_volume+0x31/0x50<br /> cachefiles_withdraw_cache+0x3ad/0x900<br /> cachefiles_put_unbind_pincount+0x1f6/0x250<br /> cachefiles_daemon_release+0x13b/0x290<br /> __fput+0x204/0xa00<br /> task_work_run+0x139/0x230<br /> <br /> Allocated by task 5820:<br /> __kmalloc+0x1df/0x4b0<br /> fscache_alloc_volume+0x70/0x600<br /> __fscache_acquire_volume+0x1c/0x610<br /> erofs_fscache_register_volume+0x96/0x1a0<br /> erofs_fscache_register_fs+0x49a/0x690<br /> erofs_fc_fill_super+0x6c0/0xcc0<br /> vfs_get_super+0xa9/0x140<br /> vfs_get_tree+0x8e/0x300<br /> do_new_mount+0x28c/0x580<br /> [...]<br /> <br /> Freed by task 5820:<br /> kfree+0xf1/0x2c0<br /> fscache_put_volume.part.0+0x5cb/0x9e0<br /> erofs_fscache_unregister_fs+0x157/0x1b0<br /> erofs_kill_sb+0xd9/0x1c0<br /> deactivate_locked_super+0xa3/0x100<br /> vfs_get_super+0x105/0x140<br /> vfs_get_tree+0x8e/0x300<br /> do_new_mount+0x28c/0x580<br /> [...]<br /> ==================================================================<br /> <br /> Following is the process that triggers the issue:<br /> <br /> mount failed | daemon exit<br /> ------------------------------------------------------------<br /> deactivate_locked_super cachefiles_daemon_release<br /> erofs_kill_sb<br /> erofs_fscache_unregister_fs<br /> fscache_relinquish_volume<br /> __fscache_relinquish_volume<br /> fscache_put_volume(fscache_volume, fscache_volume_put_relinquish)<br /> zero = __refcount_dec_and_test(&amp;fscache_volume-&gt;ref, &amp;ref);<br /> cachefiles_put_unbind_pincount<br /> cachefiles_daemon_unbind<br /> cachefiles_withdraw_cache<br /> cachefiles_withdraw_volumes<br /> list_del_init(&amp;volume-&gt;cache_link)<br /> fscache_free_volume(fscache_volume)<br /> cache-&gt;ops-&gt;free_volume<br /> cachefiles_free_volume<br /> list_del_init(&amp;cachefiles_volume-&gt;cache_link);<br /> kfree(fscache_volume)<br /> cachefiles_withdraw_volume<br /> fscache_withdraw_volume<br /> fscache_volume-&gt;n_accesses<br /> // fscache_volume UAF !!!<br /> <br /> The fscache_volume in cache-&gt;volumes must not have been freed yet, but its<br /> reference count may be 0. So use the new fscache_try_get_volume() helper<br /> function try to get its reference count.<br /> <br /> If the reference count of fscache_volume is 0, fscache_put_volume() is<br /> freeing it, so wait for it to be removed from cache-&gt;volumes.<br /> <br /> If its reference count is not 0, call cachefiles_withdraw_volume() with<br /> reference count protection to avoid the above issue.