Bug 827234 - potential to deadlock libvirt on EPIPE
potential to deadlock libvirt on EPIPE
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libvirt (Show other bugs)
6.3
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Eric Blake
Virtualization Bugs
: Security
Depends On:
Blocks: 828565
  Show dependency treegraph
 
Reported: 2012-05-31 18:54 EDT by Eric Blake
Modified: 2013-02-21 02:15 EST (History)
10 users (show)

See Also:
Fixed In Version: libvirt-0.9.13-2.el6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 828565 (view as bug list)
Environment:
Last Closed: 2013-02-21 02:15:58 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Comment 2 Dave Allan 2012-05-31 20:33:14 EDT
Eric, from our email exchange it sounds like this behavior only results in the hang of a process already controlled by a user and cannot be exploited to do anything else.  Can you confirm?
Comment 3 Eric Blake 2012-06-01 11:36:51 EDT
I've convinced myself that the deadlock can only happen if you call virCommandSetInputBuffer with more than PIPE_BUF bytes; the only places in our code base that makes these calls are security_apparmor.c (not relevant to RHEL) and hooks.c (but hooks are only run if you can install a shell hook, which means you can already do any number of other things), and therefore this is not a security bug - while it can be exploited to cause deadlock, such an exploit is not a Denial of Service where an unprivileged user is able to lock out a privileged user.  I'm opening up visibility and posting the patch upstream.
Comment 5 Eric Blake 2012-06-04 17:52:30 EDT
Now upstream:
commit 858c2476d9dccf630ad5b7f4d8e0e61e9295c2b6
Author: Eric Blake <eblake@redhat.com>
Date:   Thu May 31 15:50:07 2012 -0600

    command: avoid deadlock on EPIPE situation
    
    It is possible to deadlock libvirt by having a domain with XML
    longer than PIPE_BUF, and by writing a hook script that closes
    stdin early.  This is because libvirt was keeping a copy of the
    child's stdin read fd open, which means the write fd in the
    parent will never see EPIPE (remember, libvirt should always be
    run with SIGPIPE ignored, so we should never get a SIGPIPE signal).
    Since there is no error, libvirt blocks waiting for a write to
    complete, even though the only reader is also libvirt.  The
    solution is to ensure that only the child can act as a reader
    before the parent does any writes; and then dealing with the
    fallout of dealing with EPIPE.
Comment 7 Alex Jia 2012-07-13 04:16:51 EDT
I can reproduce this issue on 'tag v0.9.10' after applied patch of 'tests/*', and the 'commandtest' will be hung forever due to dealock:

<snip>
TEST: sockettest
      ......................................   38  OK
PASS: sockettest
TEST: commandtest
      ....................
</snip>


And it's okay without deadlock after applied patch of 'src/util/command.c'. So change the bug to VERIFIED status.
Comment 8 errata-xmlrpc 2013-02-21 02:15:58 EST
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHSA-2013-0276.html

Note You need to log in before you can comment on or make changes to this bug.