Greetings all, After some digging today I've found a bug in an error handling case for connections to AF_SYSTEM / SYSPROTO_CONTROL sockets when the kernel code (an NKE in my case) registers its handlers using ctl_flags CTL_FLAG_PRIVILEGED. If a connect() attempt is made without uid 0 (ie: one forgets to use sudo), it fails correctly with an EPERM error. But the control socket is left in an inconsistent state such that all further attempts to connect to it will fail with an EBUSY error. This is true even if the socket that failed to connect is closed. The only way to recover is to have the NKE deregister and then reregister its handlers for that signature and unit number (which for me is the same as having to unload and reload my kext). The bug is in xnu/bsd/kern_control.c, in ctl_connect() where (around line 177) it does ctl->skt = so before checking for an EPERM error and leaves it set even if an error occurs. ctl_disconnect() contributes to the problem by doing nothing if so->so_pcb is NULL which it will be if the EPERM error occurred (since the connect failed). Once this happens, all future ctl_connect() calls fail with EBUSY since ctl->skt has a value and ctl_disconnect() calls do nothing. Several fixes come to mind. I think the cleanest would be to move the assignment of ctl->skt = so down after line 184 (after the CTL_FLAG_PRIVILEGED test). As long as suser() has no memory alias to ctl->skt (which would be very ugly!) this would fix it. Next best would be to clear ctl->skt in the two error returns in the CTL_FLAG_PRIVILEGED block as is done if the registered connect() function a few lines later returns an error. (That must be done that way since that function clearly has access to ctl and hence may rightly expect ctl->skt to be set. I wouldn't think that suser() would need that and therefore setting ctl->skt so early is dubious.) Lastly, the NULLing of ctl->skt in ctl_disconnect() could be pulled out of the test of so->so_pcb so it's always cleared regardless of the connected state. I think this is poor as it muddles the meaning of a non-NULL ctl->skt but it would avoid this particular problem. If I've missed something or if there is a more formal way to submit these sorts of fixes please let me know. - Mike _______________________________________________ darwin-kernel mailing list | darwin-kernel@lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.