Make error reporting in libvirtd thread safe CVE-2011-1486
authorJiri Denemark <jdenemar@redhat.com>
Wed, 23 Mar 2011 15:00:58 +0000 (16:00 +0100)
committerJiri Denemark <jdenemar@redhat.com>
Thu, 24 Mar 2011 08:39:50 +0000 (09:39 +0100)
commitf44bfb7fb978c9313ce050a1c4149bf04aa0a670
tree33cf04faedad2c80411b2fad4162429657a2d8d5
parent9450a7cbeffebd81828785f9ce1ec1891ba5d31a
Make error reporting in libvirtd thread safe

Bug https://bugzilla.redhat.com/show_bug.cgi?id=689374 reported libvirtd
crash during error dispatch.

The reason is that libvirtd uses remoteDispatchConnError() with non-NULL
conn parameter which means that virConnGetLastError() is used instead of
its thread safe replacement virGetLastError().

So when several libvirtd threads are reporting errors at the same time,
the errors can get mixed or corrupted or in case of bad luck libvirtd
itself crashes.

Since Daniel B. is going to rewrite this code from scratch on top of his
RPC infrastructure, I tried to come up with a minimal fix. Thus,
remoteDispatchConnError() now just ignores its conn argument and always
calls virGetLastError(). However, several callers had to be touched as
well, since no libvirt API is allowed to be called before dispatching
the error. Doing so would reset the error and we would have nothing to
dispatch. As a result of that, the code is not very nice but that
doesn't really make daemon/remote.c worse than it is now :-) And it will
all die soon, which is good.

The bug report also contains a reproducer in C which detects both mixed
up error messages and libvirtd crash. Before this patch, I was able to
crash libvirtd in about 20 seconds up to 3 minutes depending on number
of CPU cores (more is better) and luck.
daemon/dispatch.c
daemon/remote.c