[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-bugs] [Bug 1162] New: [XSM] Potential security vulnerability and inconsistency in evtchn_close and evtchn_reset
http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1162 Summary: [XSM] Potential security vulnerability and inconsistency in evtchn_close and evtchn_reset Product: Xen Version: unstable Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Hypervisor AssignedTo: xen-bugs@xxxxxxxxxxxxxxxxxxx ReportedBy: tammy000@xxxxxxxxx I found that evtchn_close() is not checked for authorization by xsm hooks in some cases. There is xsm permission check before __evtchn_close() in evtchn_reset() as shown below: 785 static long evtchn_reset(evtchn_reset_t *r) 786 { ... 803 rc = xsm_evtchn_reset(current->domain, d); 804 if ( rc ) 805 goto out; 806 807 for ( i = 0; port_is_valid(d, i); i++ ) 808 (void)__evtchn_close(d, i); ... } However, there is no such xsm permission check before the __evtchn_close() called by evtchn_close() in do_event_channel_op() as below. I imagine, maybe there is no need to check if one can close itself, but it is probably still good to add a xsm hook inside evtchn_close() in case we decide to expand evtchn_close() to close other domains later. In addition, almost all other functions such as evtchn_send() and evtchn_status() put their xsm hooks inside themselves, it is more consistent to add a xsm_evtchn_close() hook in evtchn_close(). What do you think? Thanks. 818 long do_event_channel_op(int cmd, XEN_GUEST_HANDLE(void) arg) { ... 874 case EVTCHNOP_close: { 875 struct evtchn_close close; 876 if ( copy_from_guest(&close, arg, 1) != 0 ) 877 return -EFAULT; 878 rc = evtchn_close(&close); 879 break; ... } 469 static long evtchn_close(evtchn_close_t *close) 470 { 471 return __evtchn_close(current->domain, close->port); 472 } Thanks. -- Configure bugmail: http://bugzilla.xensource.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. _______________________________________________ Xen-bugs mailing list Xen-bugs@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-bugs
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |