On Fri, Jan 10, 2014 at 13:27:49 -0700, Eric Blake wrote:
On 01/10/2014 12:19 PM, Jiri Denemark wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=1047577
When a client closes its connection to libvirtd early during virConnectOpen, more specifically just after making REMOTE_PROC_CONNECT_SUPPORTS_FEATURE call to check if VIR_DRV_FEATURE_PROGRAM_KEEPALIVE is supported without even waiting for the result, libvirtd may crash due to a race in keep-alive initialization. Once receiving the REMOTE_PROC_CONNECT_SUPPORTS_FEATURE call, the daemon's event loop delegates it to a worker thread. In case the event loop detects EOF on the connection and calls virNetServerClientClose before the worker thread starts to handle REMOTE_PROC_CONNECT_SUPPORTS_FEATURE call, client->keepalive will be disposed by the time virNetServerClientStartKeepAlive gets called from remoteDispatchConnectSupportsFeature. Because the flow is common for both authenticated and read-only connections, even unprivileged clients may cause the daemon to crash.
To void the crash, virNetServerClientStartKeepAlive needs to check if
s/void/avoid/
the connection is still open before starting keep-alive protocol.
Every libvirt release since 0.9.8 is affected by this bug.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com> --- src/rpc/virnetserverclient.c | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-)
ACK. Definitely worth having in 1.2.1.
Oops, except that my reproducer which used sleep() to be reliable caused I missed that virNetServerClientClose unlocks and relocks the client object after removing client->keepalive but before removing client->sock. Thus it is still possible to call virKeepAliveStart with a NULL object with this patch. A oneliner fix is coming... Jirka