All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Cc: Xen-devel List <xen-devel@lists.xen.org>
Subject: Coverity issues with block stubdom support in libxl
Date: Wed, 20 Nov 2013 13:49:18 +0000	[thread overview]
Message-ID: <528CBDDE.6090200@citrix.com> (raw)

Hello,

Coverity has found some issues.

CID1130521 - USE_AFTER_FREE
libxl.c: device_complete().  Conditional free of aodev->dev followed by
unconditional use in the log message.  Reeording these operations would
be the sensible fix.

CID 1130517 and 1130518 - RESOURCE_LEAK
libxl_dm.c: libxl__spawn_qdisk_backend().  If libxl_spawn_spawn()
returns an error, the logfile_w and null file handles are leaked.

There was also a query about whether libxl__exec takes ownership of the
handles, which I shall defer to those who know libxl better than I.


The following are not strictly your bugs, as you only copied the code. 
However, they need fixing.

CID 1130516 - NEGATIVE_RETURNS
xl_cmdimpl.c: do_daemonize().  Coverity complains that it is possible to
dup2(logfile, 1); with logfile as -1.  It appears that the uses of
CHK_ERRNO() are bogus.  CHK_ERRNO() itself tests for "(call) < 0".  In
do_daemonize(), the tests therefore become "if ( ((call) < 0) < 0 )"
which fails to catch the error condition.  I suspect removing the
trailing "<0" in the CHK_ERRNO() calls should fix the error (but I would
appreciate a second opinion on this).

I believe that the above is also the cause of CID 1130519 -
RESOURCE_LEAK leaking nullfd.

CID 1130520 - UNREACHABLE
xl_cmdimpl.c: do_daemonize().  The "for (;;)" is bogus.  The body of the
loop unconditionally exits on the first iteration.

~Andrew

             reply	other threads:[~2013-11-20 13:49 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-20 13:49 Andrew Cooper [this message]
2013-11-20 14:02 ` Coverity issues with block stubdom support in libxl Ian Campbell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=528CBDDE.6090200@citrix.com \
    --to=andrew.cooper3@citrix.com \
    --cc=roger.pau@citrix.com \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.