CVE-2024-41057

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cachefiles: fix slab-use-after-free in cachefiles_withdraw_cookie()<br /> <br /> We got the following issue in our fault injection stress test:<br /> <br /> ==================================================================<br /> BUG: KASAN: slab-use-after-free in cachefiles_withdraw_cookie+0x4d9/0x600<br /> Read of size 8 at addr ffff888118efc000 by task kworker/u78:0/109<br /> <br /> CPU: 13 PID: 109 Comm: kworker/u78:0 Not tainted 6.8.0-dirty #566<br /> Call Trace:<br /> <br /> kasan_report+0x93/0xc0<br /> cachefiles_withdraw_cookie+0x4d9/0x600<br /> fscache_cookie_state_machine+0x5c8/0x1230<br /> fscache_cookie_worker+0x91/0x1c0<br /> process_one_work+0x7fa/0x1800<br /> [...]<br /> <br /> Allocated by task 117:<br /> kmalloc_trace+0x1b3/0x3c0<br /> cachefiles_acquire_volume+0xf3/0x9c0<br /> fscache_create_volume_work+0x97/0x150<br /> process_one_work+0x7fa/0x1800<br /> [...]<br /> <br /> Freed by task 120301:<br /> kfree+0xf1/0x2c0<br /> cachefiles_withdraw_cache+0x3fa/0x920<br /> cachefiles_put_unbind_pincount+0x1f6/0x250<br /> cachefiles_daemon_release+0x13b/0x290<br /> __fput+0x204/0xa00<br /> task_work_run+0x139/0x230<br /> do_exit+0x87a/0x29b0<br /> [...]<br /> ==================================================================<br /> <br /> Following is the process that triggers the issue:<br /> <br /> p1 | p2<br /> ------------------------------------------------------------<br /> fscache_begin_lookup<br /> fscache_begin_volume_access<br /> fscache_cache_is_live(fscache_cache)<br /> cachefiles_daemon_release<br /> cachefiles_put_unbind_pincount<br /> cachefiles_daemon_unbind<br /> cachefiles_withdraw_cache<br /> fscache_withdraw_cache<br /> fscache_set_cache_state(cache, FSCACHE_CACHE_IS_WITHDRAWN);<br /> cachefiles_withdraw_objects(cache)<br /> fscache_wait_for_objects(fscache)<br /> atomic_read(&amp;fscache_cache-&gt;object_count) == 0<br /> fscache_perform_lookup<br /> cachefiles_lookup_cookie<br /> cachefiles_alloc_object<br /> refcount_set(&amp;object-&gt;ref, 1);<br /> object-&gt;volume = volume<br /> fscache_count_object(vcookie-&gt;cache);<br /> atomic_inc(&amp;fscache_cache-&gt;object_count)<br /> cachefiles_withdraw_volumes<br /> cachefiles_withdraw_volume<br /> fscache_withdraw_volume<br /> __cachefiles_free_volume<br /> kfree(cachefiles_volume)<br /> fscache_cookie_state_machine<br /> cachefiles_withdraw_cookie<br /> cache = object-&gt;volume-&gt;cache;<br /> // cachefiles_volume UAF !!!<br /> <br /> After setting FSCACHE_CACHE_IS_WITHDRAWN, wait for all the cookie lookups<br /> to complete first, and then wait for fscache_cache-&gt;object_count == 0 to<br /> avoid the cookie exiting after the volume has been freed and triggering<br /> the above issue. Therefore call fscache_withdraw_volume() before calling<br /> cachefiles_withdraw_objects().<br /> <br /> This way, after setting FSCACHE_CACHE_IS_WITHDRAWN, only the following two<br /> cases will occur:<br /> 1) fscache_begin_lookup fails in fscache_begin_volume_access().<br /> 2) fscache_withdraw_volume() will ensure that fscache_count_object() has<br /> been executed before calling fscache_wait_for_objects().