Blame xen-xenstored-fix.diff
|
 |
5b4649f |
There is a use-after-free bug in xenstored.
|
|
|
5b4649f |
|
|
|
5b4649f |
Problem: Handling requests for one connection can not only zap the
|
|
|
5b4649f |
connection itself, due to socket disconnects for example. It can also
|
|
|
5b4649f |
zap *other* connections, due to domain release requests. Especially it
|
|
|
5b4649f |
can zap the connection we have saved a pointer to in the "next"
|
|
|
5b4649f |
variable.
|
|
|
5b4649f |
|
|
|
5b4649f |
The attached patch fixes it by adjusting the reference counting.
|
|
|
5b4649f |
|
|
|
5b4649f |
diff -r 8417ddc981b4 tools/xenstore/xenstored_core.c
|
|
|
5b4649f |
--- a/tools/xenstore/xenstored_core.c Mon Jan 05 11:10:54 2009 +0000
|
|
|
5b4649f |
+++ b/tools/xenstore/xenstored_core.c Thu Feb 26 18:22:31 2009 +0100
|
|
|
5b4649f |
@@ -1937,14 +1937,17 @@
|
|
|
5b4649f |
handle_event();
|
|
|
5b4649f |
|
|
|
5b4649f |
next = list_entry(connections.next, typeof(*conn), list);
|
|
|
5b4649f |
+ if (&next->list != &connections)
|
|
|
5b4649f |
+ talloc_increase_ref_count(next);
|
|
|
5b4649f |
while (&next->list != &connections) {
|
|
|
5b4649f |
conn = next;
|
|
|
5b4649f |
|
|
|
5b4649f |
next = list_entry(conn->list.next,
|
|
|
5b4649f |
typeof(*conn), list);
|
|
|
5b4649f |
+ if (&next->list != &connections)
|
|
|
5b4649f |
+ talloc_increase_ref_count(next);
|
|
|
5b4649f |
|
|
|
5b4649f |
if (conn->domain) {
|
|
|
5b4649f |
- talloc_increase_ref_count(conn);
|
|
|
5b4649f |
if (domain_can_read(conn))
|
|
|
5b4649f |
handle_input(conn);
|
|
|
5b4649f |
if (talloc_free(conn) == 0)
|
|
|
5b4649f |
@@ -1957,7 +1960,6 @@
|
|
|
5b4649f |
if (talloc_free(conn) == 0)
|
|
|
5b4649f |
continue;
|
|
|
5b4649f |
} else {
|
|
|
5b4649f |
- talloc_increase_ref_count(conn);
|
|
|
5b4649f |
if (FD_ISSET(conn->fd, &inset))
|
|
|
5b4649f |
handle_input(conn);
|
|
|
5b4649f |
if (talloc_free(conn) == 0)
|