Files
linux-bredos/include/linux
Michael Kelley 07a756a49f 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.

Reported-by: Dexuan Cui <decui@microsoft.com>
Fixes: e0fa3e5e7d ("Drivers: hv: utils: fix a race on userspace daemons registration")
Cc: stable@vger.kernel.org
Signed-off-by: Michael Kelley <mhklinux@outlook.com>
Acked-by: Wei Liu <wei.liu@kernel.org>
Link: https://lore.kernel.org/r/20241106154247.2271-3-mhklinux@outlook.com
Signed-off-by: Wei Liu <wei.liu@kernel.org>
Message-ID: <20241106154247.2271-3-mhklinux@outlook.com>
2024-12-09 18:44:15 +00:00
..
2024-10-22 15:54:11 +02:00
2024-10-11 14:34:11 -04:00
2024-10-13 17:16:57 +02:00
2024-10-11 14:37:29 +05:30
2024-10-14 23:27:57 +05:30
2024-11-11 10:45:03 +01:00
2024-10-09 15:42:48 +01:00
2024-11-11 09:06:45 -07:00
2024-11-07 14:38:07 -08:00
2024-10-14 18:33:04 -07:00
2024-11-05 13:32:21 +01:00
2024-10-22 11:16:56 +02:00
2024-10-19 14:16:45 +02:00
2024-10-01 17:01:40 +02:00
2024-11-09 14:55:33 +01:00
2024-11-28 14:49:28 +01:00
2024-11-24 17:05:27 -08:00
2024-10-16 21:56:59 +02:00
2024-10-30 19:47:20 +01:00
2024-11-05 16:56:26 -08:00
2024-10-14 16:33:24 -05:00
2024-11-05 16:56:26 -08:00
2024-11-16 10:09:30 -06:00
2024-10-02 16:23:10 -05:00
2024-11-05 12:55:38 +01:00
2024-11-30 22:41:35 -05:00
2024-11-11 00:26:44 -08:00
2024-11-06 12:59:44 -05:00
2024-10-02 16:53:38 +02:00
2024-11-18 11:56:21 +00:00
2024-11-06 12:59:44 -05:00