Drivers: hv: util: Avoid accessing a ringbuffer not initialized yet

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.