Potential use of freed memory in event channel operations

Wrong ordering of operations upon extending the per-domain event channel tracking table can cause a pointer to freed memory to be left in place, when the hypervisor is under memory pressure and XSM (Xen Security Module) is enabled.

use-after-free (wrong ordering of operations)



defer event channel bucket pointer store until after XSM checks

Otherwise a dangling pointer can be left, which would cause subsequent memory corruption as soon as the space got re-allocated for some other purpose.

--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -104,7 +104,6 @@ static int get_free_port(struct domain *
     if ( unlikely(chn == NULL) )
         return -ENOMEM;
     memset(chn, 0, EVTCHNS_PER_BUCKET * sizeof(*chn));
-    bucket_from_port(d, port) = chn;
     for ( i = 0; i < EVTCHNS_PER_BUCKET; i++ )
@@ -117,6 +116,8 @@ static int get_free_port(struct domain *
+    bucket_from_port(d, port) = chn;
     return port;


Malicious guest kernels could inject arbitrary events or corrupt other hypervisor state, possibly leading to code execution.

DoS, code execution