Skip to content

L
libvirt

openeuler / libvirt

通知 3
Star 0
Fork 0
L
libvirt

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 28 9月, 2017 2 次提交
    • J
      nwfilter: Fix possible segfault on sometimes consumed variable · 6209bb32
      由 John Ferlan 提交于 
      The virNWFilterIPAddrMapAddIPAddr code can consume the @addr parameter
on success when the @ifname is found in the ipAddressMap->hashTable
hash table in the call to virNWFilterVarValueAddValue; however, if
not found in the hash table, then @addr is formatted into a @val
which is stored in the table and on return the caller would be
expected to free @addr.

Thus, the caller has no way to determine on success whether @addr was
consumed, so in order to fix this create a @tmp variable which will
be stored/consumed when virNWFilterVarValueAddValue succeeds. That way
the caller can free @addr whether the function returns success or failure.
      6209bb32
    • P
      rpc: for messages with FDs always decode count of FDs from the message · 5c52aed1
      由 Pavel Hrdina 提交于 
      The packet with passed FD has the following format:

    --------------------------
    | len | header | payload |
    --------------------------

where "payload" has an additional count of FDs before the actual data:

    ------------------
    | nfds | payload |
    ------------------

When the packet is received we parse the "header", which as a side
effect updates msg->bufferOffset to point to the beginning of "payload".
If the message call contains FDs, we need to also parse the count of
FDs, which also updates the msg->bufferOffset.

The issue here is that when we attempt to read the FDs data from the
socket and we receive EAGAIN we finish the reading and call poll()
to wait for the data the we need.  When the data arrives we already have
the packet in our buffer so we read the "header" again but this time
we don't read the count of FDs because we already have it stored.

That means that the msg->bufferOffset is not updated to point to the
actual beginning of the payload data, but it points to the count of
FDs.  After all FDs are processed we dispatch the message to process
it and decode the payload.  Since the msg->bufferOffset points to wrong
data, we decode the wrong payload and the API call fails with
error messages:

    Domain not found: no domain with matching uuid '67656e65-7269-6300-0c87-5003ca6941f2' ()

Broken by commit 133c511b which fixed a FD and memory leak.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
      5c52aed1
  3. 27 9月, 2017 12 次提交
  5. 26 9月, 2017 3 次提交
  7. 25 9月, 2017 4 次提交
  9. 22 9月, 2017 12 次提交
  11. 21 9月, 2017 7 次提交