{"uuid": "3b9dc2f8-82f4-4092-b844-602041a71e72", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-45000", "type": "seen", "source": "https://t.me/cvedetector/4871", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-45000 - HP ProLiant Linux Kernel Null Pointer Dereference Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-45000 \nPublished : Sept. 4, 2024, 8:15 p.m. | 27\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nfs/netfs/fscache_cookie: add missing \"n_accesses\" check  \n  \nThis fixes a NULL pointer dereference bug due to a data race which  \nlooks like this:  \n  \n  BUG: kernel NULL pointer dereference, address: 0000000000000008  \n  #PF: supervisor read access in kernel mode  \n  #PF: error_code(0x0000) - not-present page  \n  PGD 0 P4D 0  \n  Oops: 0000 [#1] SMP PTI  \n  CPU: 33 PID: 16573 Comm: kworker/u97:799 Not tainted 6.8.7-cm4all1-hp+ #43  \n  Hardware name: HP ProLiant DL380 Gen9/ProLiant DL380 Gen9, BIOS P89 10/17/2018  \n  Workqueue: events_unbound netfs_rreq_write_to_cache_work  \n  RIP: 0010:cachefiles_prepare_write+0x30/0xa0  \n  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  \n  RSP: 0018:ffffb4e78113bde0 EFLAGS: 00010286  \n  RAX: ffff976126be6d10 RBX: ffff97615cdb8438 RCX: 0000000000020000  \n  RDX: ffff97605e6c4c68 RSI: ffff97605e6c4c60 RDI: ffff97615cdb8438  \n  RBP: 0000000000000000 R08: 0000000000278333 R09: 0000000000000001  \n  R10: ffff97605e6c4600 R11: 0000000000000001 R12: ffff97605e6c4c68  \n  R13: 0000000000020000 R14: 0000000000000001 R15: ffff976064fe2c00  \n  FS:  0000000000000000(0000) GS:ffff9776dfd40000(0000) knlGS:0000000000000000  \n  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033  \n  CR2: 0000000000000008 CR3: 000000005942c002 CR4: 00000000001706f0  \n  Call Trace:  \n     \n   ? __die+0x1f/0x70  \n   ? page_fault_oops+0x15d/0x440  \n   ? search_module_extables+0xe/0x40  \n   ? fixup_exception+0x22/0x2f0  \n   ? exc_page_fault+0x5f/0x100  \n   ? asm_exc_page_fault+0x22/0x30  \n   ? cachefiles_prepare_write+0x30/0xa0  \n   netfs_rreq_write_to_cache_work+0x135/0x2e0  \n   process_one_work+0x137/0x2c0  \n   worker_thread+0x2e9/0x400  \n   ? __pfx_worker_thread+0x10/0x10  \n   kthread+0xcc/0x100  \n   ? __pfx_kthread+0x10/0x10  \n   ret_from_fork+0x30/0x50  \n   ? __pfx_kthread+0x10/0x10  \n   ret_from_fork_asm+0x1b/0x30  \n     \n  Modules linked in:  \n  CR2: 0000000000000008  \n  ---[ end trace 0000000000000000 ]---  \n  \nThis happened because fscache_cookie_state_machine() was slow and was  \nstill running while another process invoked fscache_unuse_cookie();  \nthis led to a fscache_cookie_lru_do_one() call, setting the  \nFSCACHE_COOKIE_DO_LRU_DISCARD flag, which was picked up by  \nfscache_cookie_state_machine(), withdrawing the cookie via  \ncachefiles_withdraw_cookie(), clearing cookie->cache_priv.  \n  \nAt the same time, yet another process invoked  \ncachefiles_prepare_write(), which found a NULL pointer in this code  \nline:  \n  \n  struct cachefiles_object *object = cachefiles_cres_object(cres);  \n  \nThe next line crashes, obviously:  \n  \n  struct cachefiles_cache *cache = object->volume->cache;  \n  \nDuring cachefiles_prepare_write(), the \"n_accesses\" counter is  \nnon-zero (via fscache_begin_operation()).  The cookie must not be  \nwithdrawn until it drops to zero.  \n  \nThe counter is checked by fscache_cookie_state_machine() before  \nswitching to FSCACHE_COOKIE_STATE_RELINQUISHING and  \nFSCACHE_COOKIE_STATE_WITHDRAWING (in \"case  \nFSCACHE_COOKIE_STATE_FAILED\"), but not for  \nFSCACHE_COOKIE_STATE_LRU_DISCARDING (\"case  \nFSCACHE_COOKIE_STATE_ACTIVE\").  \n  \nThis patch adds the missing check.  With a non-zero access counter,  \nthe function returns and the next fscache_end_cookie_access() call  \nwill queue another fscache_cookie_state_machine() call to handle the  \nstill-pending FSCACHE_COOKIE_DO_LRU_DISCARD. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"04 Sep 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-09-04T22:48:16.000000Z"}