{"vulnerability": "CVE-2024-55916", "sightings": [{"uuid": "9e09e957-ba5d-4fd4-ba78-4c32abc971e5", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-55916", "type": "seen", "source": "https://bsky.app/profile/cve-notifications.bsky.social/post/3lfhs5tyorp2a", "content": "", "creation_timestamp": "2025-01-11T13:17:15.191823Z"}, {"uuid": "65497d63-04c3-4c18-b287-b89e2275f432", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-55916", "type": "published-proof-of-concept", "source": "https://t.me/cvedetector/15069", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-55916 - Hyper-V Drivers: Buffer Not Initialized Yet NULL Pointer Dereference Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-55916 \nPublished : Jan. 11, 2025, 1:15 p.m. | 35\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nDrivers: hv: util: Avoid accessing a ringbuffer not initialized yet  \n  \nIf the KVP (or VSS) daemon starts before the VMBus channel's ringbuffer is  \nfully initialized, we can hit the panic below:  \n  \nhv_utils: Registering HyperV Utility Driver  \nhv_vmbus: registering driver hv_utils  \n...  \nBUG: kernel NULL pointer dereference, address: 0000000000000000  \nCPU: 44 UID: 0 PID: 2552 Comm: hv_kvp_daemon Tainted: G E 6.11.0-rc3+ #1  \nRIP: 0010:hv_pkt_iter_first+0x12/0xd0  \nCall Trace:  \n...  \n vmbus_recvpacket  \n hv_kvp_onchannelcallback  \n vmbus_on_event  \n tasklet_action_common  \n tasklet_action  \n handle_softirqs  \n irq_exit_rcu  \n sysvec_hyperv_stimer0  \n   \n   \n asm_sysvec_hyperv_stimer0  \n...  \n kvp_register_done  \n hvt_op_read  \n vfs_read  \n ksys_read  \n __x64_sys_read  \n  \nThis can happen because the KVP/VSS channel callback can be invoked  \neven before the channel is fully opened:  \n1) as soon as hv_kvp_init() -> hvutil_transport_init() creates  \n/dev/vmbus/hv_kvp, the kvp daemon can open the device file immediately and  \nregister itself to the driver by writing a message KVP_OP_REGISTER1 to the  \nfile (which is handled by kvp_on_msg() ->kvp_handle_handshake()) and  \nreading the file for the driver's response, which is handled by  \nhvt_op_read(), which calls hvt->on_read(), i.e. kvp_register_done().  \n  \n2) the problem with kvp_register_done() is that it can cause the  \nchannel callback to be called even before the channel is fully opened,  \nand when the channel callback is starting to run, util_probe()->  \nvmbus_open() may have not initialized the ringbuffer yet, so the  \ncallback can hit the panic of NULL pointer dereference.  \n  \nTo reproduce the panic consistently, we can add a \"ssleep(10)\" for KVP in  \n__vmbus_open(), just before the first hv_ringbuffer_init(), and then we  \nunload and reload the driver hv_utils, and run the daemon manually within  \nthe 10 seconds.  \n  \nFix the panic by reordering the steps in util_probe() so the char dev  \nentry used by the KVP or VSS daemon is not created until after  \nvmbus_open() has completed. This reordering prevents the race condition  \nfrom happening. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"11 Jan 2025\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2025-01-11T14:55:23.000000Z"}]}