CVE-2024-45000

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/netfs/fscache_cookie: add missing "n_accesses" check<br /> <br /> This fixes a NULL pointer dereference bug due to a data race which<br /> looks like this:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000008<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> PGD 0 P4D 0<br /> Oops: 0000 [#1] SMP PTI<br /> CPU: 33 PID: 16573 Comm: kworker/u97:799 Not tainted 6.8.7-cm4all1-hp+ #43<br /> Hardware name: HP ProLiant DL380 Gen9/ProLiant DL380 Gen9, BIOS P89 10/17/2018<br /> Workqueue: events_unbound netfs_rreq_write_to_cache_work<br /> RIP: 0010:cachefiles_prepare_write+0x30/0xa0<br /> Code: 57 41 56 45 89 ce 41 55 49 89 cd 41 54 49 89 d4 55 53 48 89 fb 48 83 ec 08 48 8b 47 08 48 83 7f 10 00 48 89 34 24 48 8b 68 20 8b 45 08 4c 8b 38 74 45 49 8b 7f 50 e8 4e a9 b0 ff 48 8b 73 10<br /> RSP: 0018:ffffb4e78113bde0 EFLAGS: 00010286<br /> RAX: ffff976126be6d10 RBX: ffff97615cdb8438 RCX: 0000000000020000<br /> RDX: ffff97605e6c4c68 RSI: ffff97605e6c4c60 RDI: ffff97615cdb8438<br /> RBP: 0000000000000000 R08: 0000000000278333 R09: 0000000000000001<br /> R10: ffff97605e6c4600 R11: 0000000000000001 R12: ffff97605e6c4c68<br /> R13: 0000000000020000 R14: 0000000000000001 R15: ffff976064fe2c00<br /> FS: 0000000000000000(0000) GS:ffff9776dfd40000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000008 CR3: 000000005942c002 CR4: 00000000001706f0<br /> Call Trace:<br /> <br /> ? __die+0x1f/0x70<br /> ? page_fault_oops+0x15d/0x440<br /> ? search_module_extables+0xe/0x40<br /> ? fixup_exception+0x22/0x2f0<br /> ? exc_page_fault+0x5f/0x100<br /> ? asm_exc_page_fault+0x22/0x30<br /> ? cachefiles_prepare_write+0x30/0xa0<br /> netfs_rreq_write_to_cache_work+0x135/0x2e0<br /> process_one_work+0x137/0x2c0<br /> worker_thread+0x2e9/0x400<br /> ? __pfx_worker_thread+0x10/0x10<br /> kthread+0xcc/0x100<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork+0x30/0x50<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork_asm+0x1b/0x30<br /> <br /> Modules linked in:<br /> CR2: 0000000000000008<br /> ---[ end trace 0000000000000000 ]---<br /> <br /> This happened because fscache_cookie_state_machine() was slow and was<br /> still running while another process invoked fscache_unuse_cookie();<br /> this led to a fscache_cookie_lru_do_one() call, setting the<br /> FSCACHE_COOKIE_DO_LRU_DISCARD flag, which was picked up by<br /> fscache_cookie_state_machine(), withdrawing the cookie via<br /> cachefiles_withdraw_cookie(), clearing cookie-&gt;cache_priv.<br /> <br /> At the same time, yet another process invoked<br /> cachefiles_prepare_write(), which found a NULL pointer in this code<br /> line:<br /> <br /> struct cachefiles_object *object = cachefiles_cres_object(cres);<br /> <br /> The next line crashes, obviously:<br /> <br /> struct cachefiles_cache *cache = object-&gt;volume-&gt;cache;<br /> <br /> During cachefiles_prepare_write(), the "n_accesses" counter is<br /> non-zero (via fscache_begin_operation()). The cookie must not be<br /> withdrawn until it drops to zero.<br /> <br /> The counter is checked by fscache_cookie_state_machine() before<br /> switching to FSCACHE_COOKIE_STATE_RELINQUISHING and<br /> FSCACHE_COOKIE_STATE_WITHDRAWING (in "case<br /> FSCACHE_COOKIE_STATE_FAILED"), but not for<br /> FSCACHE_COOKIE_STATE_LRU_DISCARDING ("case<br /> FSCACHE_COOKIE_STATE_ACTIVE").<br /> <br /> This patch adds the missing check. With a non-zero access counter,<br /> the function returns and the next fscache_end_cookie_access() call<br /> will queue another fscache_cookie_state_machine() call to handle the<br /> still-pending FSCACHE_COOKIE_DO_LRU_DISCARD.