On 03/15/2013 01:26 PM, Eric Blake wrote:
On 03/15/2013 10:16 AM, Gene Czarcinski wrote:
On 03/15/2013 11:38 AM, Eric Blake wrote:
On 03/15/2013 07:48 AM, Gene Czarcinski wrote:
One of the libvirt tests (conftest) has been segfaulting for some time
with no indication of a test failure other than a message in syslog. I
verified this by building libvirt-1.0.3-1 with mock.
Generally, this is not an issue. Autoconf tests INTENTIONALLY try to
probe for broken systems, in order to work around brokenness, so a
segfaulting conftest during ./configure just says that things are
probing as expected. About the only thing that could be done to avoid a
segfault during ./configure is fixing the underlying broken system that
the probe was detecting in the first place, but that's more likely to be
a glibc or kernel fix, not a libvirt fix.
Isn't it a bit strange that it is broken under v1.0.3-maint but not
under v1.0.2-maint? The underlying system is the same.
It's not broken. If instead you mean, "Isn't it strange that a
configure triggers a conftest segfault under v1.0.3-maint but not under
v1.0.2-maint?", the answer is no, it's not strange - v1.0.3 has more
probes entered into than v1.0.2, so the new segfault is probably due to
one of those added probes.
Knowing WHICH configure.ac probe is segfaulting might be nice, for
diagnosing why it is faulting and where to send a bug report upstream.
For example, if the bug is in glibc, then fixing glibc to not segfault
will fix every program that relies on glibc without probing for the bug
- but it will have no difference to libvirt which is already prepared to
work around the glibc bug.
Look through the config.log of your 1.0.3 build to see if it you can
quickly spot a test that failed with a segfault. There's a wealth of
information in that file (maybe as simple as finding the string '$? =
139' or a message about a SEGV). But again, a segfault of conftest
during configure is NORMAL, and nothing to panic about - it means that
the package is PROPERLY going to avoid tickling that bug later on when
the package is compiled.
In fact, just in typing that, I though of at least one glibc CVE bug in
re_compile_pattern, that still has not been fixed as of the glibc
currently in Fedora 18. Furthermore, I know that this bug was reported
only recently, and that the version of gnulib used in v1.0.2 did not
check for this bug, while the version in v1.0.3 does (see libvirt commit
d09949e29 for where I updated to newer gnulib, precisely to work around
that glibc CVE). So sure enough, I looked through my config.log and found:
configure:31277: checking for working re_compile_pattern
configure:31456: gcc -std=gnu99 -o conftest -g conftest.c >&5
configure:31456: $? = 0
configure:31456: ./conftest
*** glibc detected *** ./conftest: malloc(): memory corruption:
0x0000000000b31fc0 ***
./configure: line 3528: 15097 Segmentation fault (core dumped)
./conftest$ac_exeext
configure:31456: $? = 139
configure: program exited with status 139
Libvirt is immune to that bug, but the CVE still affects other glibc
clients that use re_compile_pattern without being aware of the problems,
so you may want to put some pressure on the right people to fix
https://bugzilla.redhat.com/show_bug.cgi?id=905877.
I did a little testing and the problem begins occurring with this commit:
commit d09949e29386c38443c82a2231240cc1e3954a5d
Author: Eric Blake <eblake@xxxxxxxxxx>
Date: Sat Jan 26 13:41:31 2013 -0700
maint: update to latest gnulib
CVE-2013-0242 in glibc's regex() can cause a DoS in any daemon
that runs a regex search on user input while in a multibyte locale.
I'm not sure how hard it would be to trigger such a setup for
libvirtd, but rather than risk things, we can avoid the issue:
gnulib has worked around the problem, and by updating to the latest
gnulib, we can avoid the bug even on platforms where glibc has yet
to be patched.
* .gnulib: Update to latest, for various fixes, including regex.
* bootstrap: Resync from upstream.
If do a ./autogen with the previous commit, no problem. Move along to
this commit and "bang" ... the segfault message in syslog.
So, it appears the this version of gnulib fixes something important but
also causes a segfault when ./configure is run with the new gnulib.
What I do not know is if this segfault has any meaning.
Gene
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list