Executive Summary
Informations | |||
---|---|---|---|
Name | CVE-2024-55916 | First vendor Publication | 2025-01-11 |
Vendor | Cve | Last vendor Modification | 2025-01-16 |
Security-Database Scoring CVSS v3
Cvss vector : CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H | |||
---|---|---|---|
Overall CVSS Score | 5.5 | ||
Base Score | 5.5 | Environmental Score | 5.5 |
impact SubScore | 3.6 | Temporal Score | 5.5 |
Exploitabality Sub Score | 1.8 | ||
Attack Vector | Local | Attack Complexity | Low |
Privileges Required | Low | User Interaction | None |
Scope | Unchanged | Confidentiality Impact | None |
Integrity Impact | None | Availability Impact | High |
Calculate full CVSS 3.0 Vectors scores |
Security-Database Scoring CVSS v2
Cvss vector : | |||
---|---|---|---|
Cvss Base Score | N/A | Attack Range | N/A |
Cvss Impact Score | N/A | Attack Complexity | N/A |
Cvss Expoit Score | N/A | Authentication | N/A |
Calculate full CVSS 2.0 Vectors scores |
Detail
In the Linux kernel, the following vulnerability has been resolved: Drivers: hv: util: Avoid accessing a ringbuffer not initialized yet If the KVP (or VSS) daemon starts before the VMBus channel's ringbuffer is fully initialized, we can hit the panic below: hv_utils: Registering HyperV Utility Driver hv_vmbus: registering driver hv_utils ... BUG: kernel NULL pointer dereference, address: 0000000000000000 CPU: 44 UID: 0 PID: 2552 Comm: hv_kvp_daemon Tainted: G E 6.11.0-rc3+ #1 RIP: 0010:hv_pkt_iter_first+0x12/0xd0 Call Trace: ... This can happen because the KVP/VSS channel callback can be invoked even before the channel is fully opened: 1) as soon as hv_kvp_init() -> hvutil_transport_init() creates /dev/vmbus/hv_kvp, the kvp daemon can open the device file immediately and register itself to the driver by writing a message KVP_OP_REGISTER1 to the file (which is handled by kvp_on_msg() ->kvp_handle_handshake()) and reading the file for the driver's response, which is handled by hvt_op_read(), which calls hvt->on_read(), i.e. kvp_register_done(). 2) the problem with kvp_register_done() is that it can cause the channel callback to be called even before the channel is fully opened, and when the channel callback is starting to run, util_probe()-> vmbus_open() may have not initialized the ringbuffer yet, so the callback can hit the panic of NULL pointer dereference. To reproduce the panic consistently, we can add a "ssleep(10)" for KVP in __vmbus_open(), just before the first hv_ringbuffer_init(), and then we unload and reload the driver hv_utils, and run the daemon manually within the 10 seconds. Fix the panic by reordering the steps in util_probe() so the char dev entry used by the KVP or VSS daemon is not created until after vmbus_open() has completed. This reordering prevents the race condition from happening. |
Original Source
Url : http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-55916 |
CWE : Common Weakness Enumeration
% | Id | Name |
---|---|---|
100 % | CWE-476 | NULL Pointer Dereference |
CPE : Common Platform Enumeration
Sources (Detail)
Alert History
Date | Informations |
---|---|
2025-06-26 02:38:12 |
|
2025-06-25 12:36:16 |
|
2025-06-24 02:42:51 |
|
2025-05-27 02:48:16 |
|
2025-03-29 03:44:08 |
|
2025-03-28 13:47:27 |
|
2025-03-28 03:21:57 |
|
2025-03-25 03:28:14 |
|
2025-03-19 03:16:50 |
|
2025-03-18 03:29:49 |
|
2025-03-14 03:16:57 |
|
2025-03-06 14:13:29 |
|
2025-02-22 03:27:01 |
|
2025-01-16 21:20:39 |
|
2025-01-11 17:20:27 |
|