In article <x7bmjabmv3....@ren.fdy2.co.uk>, Robert Swindells <r...@fdy2.co.uk> wrote: > >I wrote: >>Does anyone know why we don't use the input 'optlen' parameter to the >>getsockopt(2) syscall, we do write back to it on return. >> >>In ip_output() there is this, which suggests that someone had come >>across this before. >> >>#if 0 /* defined(IPSEC) */ >> case IP_IPSEC_POLICY: >> { >> struct mbuf *m = NULL; >> >> /* XXX this will return EINVAL as sopt is empty */ >> error = ipsec4_get_policy(inp, sopt->sopt_data, >> sopt->sopt_size, &m); >> if (error == 0) >> error = sockopt_setmbuf(sopt, m); >> break; >> } >>#endif /*IPSEC*/ >> >>There are also lots of places in sctp_usrreq that want to use it. >> >>I can set it with the following patch (line numbers will be slightly >>out), but wondered if there was a reason for the current behaviour. >> >>Index: uipc_syscalls.c >>=================================================================== >>RCS file: /cvsroot/src/sys/kern/uipc_syscalls.c,v >>retrieving revision 1.187 >>diff -u -r1.187 uipc_syscalls.c >>--- uipc_syscalls.c 20 Jun 2017 20:34:49 -0000 1.187 >>+++ uipc_syscalls.c 14 Oct 2017 21:33:09 -0000 >>@@ -1235,7 +1240,7 @@ >> if ((error = fd_getsock1(SCARG(uap, s), &so, &fp)) != 0) >> return (error); >> >>- sockopt_init(&sopt, SCARG(uap, level), SCARG(uap, name), 0); >>+ sockopt_init(&sopt, SCARG(uap, level), SCARG(uap, name), valsize); >> >> if (fp->f_flag & FNOSIGPIPE) >> so->so_options |= SO_NOSIGPIPE; > >Has anyone had any other thoughts on this ?
Yes, if you don't protect valsize against MCLBYTES like setsockopt does, it can be used to DoS kernel. Otherwise is can be done. Is 2K enough? >I'm thinking of adding an extra socket option, maybe SO_PARAM, that you >would use with setsockopt(2) to set a selector to be used by a following >getsockopt(2) call. This would require some state keeping in the kernel and might not be reliable. >This wouldn't fix the IPSEC usage without changing userland though. > >The alternative is to make both setsockopt(2) and getsockopt(2) >bidirectional. So depending on the contents of the sockval we do something different? >I haven't checked in the userland implementation of sctp_opt_info(3) >yet. I took the one from FreeBSD but can modify it to work with a >different API. Ok. christos