Detections
Analytics

Google: sys-kernel/lakitu-kernel-5_15, sys-kernel/lakitu-kernel-6_1: security update to 17800.436.4

medium Tenable Self-Hosted Container Security Plugin ID 452246

Description

There are packages installed that are affected by a vulnerability referenced in the following CVE:

 - 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: ... vmbus_recvpacket hv_kvp_onchannelcallback vmbus_on_event tasklet_action_common
 tasklet_action handle_softirqs irq_exit_rcu sysvec_hyperv_stimer0 </IRQ> <TASK> asm_sysvec_hyperv_stimer0
 ... kvp_register_done hvt_op_read vfs_read ksys_read __x64_sys_read 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. (CVE-2024-55916)

Solution

Update the sys-kernel/lakitu-kernel-5_15 library and its related packages to version 17800.436.4 or later.

See Also

https://storage.googleapis.com/cos-oval-vulnerability-feed/cos-109.oval.xml.tar.gz

Plugin Details

Severity: Medium

ID: 452246

Version: Revision 1.1

Type: Local

Published: 10/1/2026

Updated: 10/1/2026

Risk Information

VPR

Risk Factor: Low

Score: 3

Percentile: 23.18

Vendor

Vendor Severity: MEDIUM

CVSS v2

Risk Factor: Medium

Base Score: 4.6

Temporal Score: 3.4

Vector: CVSS2#AV:L/AC:L/Au:S/C:N/I:N/A:C

CVSS Score Source: CVE-2024-55916

CVSS v3

Risk Factor: Medium

Base Score: 5.5

Temporal Score: 4.8

Vector: CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Temporal Vector: CVSS:3.0/E:U/RL:O/RC:C

Vulnerability Information

Exploit Ease: No known exploits are available

Vulnerability Publication Date: 1/11/2025

Reference Information

CVE: CVE-2024-55916