Re: Bug fix for kern_control.c
Re: Bug fix for kern_control.c
- Subject: Re: Bug fix for kern_control.c
- From: Vincent Lubet <email@hidden>
- Date: Tue, 12 Nov 2002 16:58:53 -0800
Michael,
The best way to get this fixed ASAP is for you to file a problem report
to
https://bugreport.apple.com and/or to contact your DTS
representative.
Vincent Lubet
On Tuesday, November 12, 2002, at 12:09 PM, Michael Cashwell wrote:
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 | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/darwin-kernel
Do not post admin requests to the list. They will be ignored.
_______________________________________________
darwin-kernel mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/darwin-kernel
Do not post admin requests to the list. They will be ignored.