tech-kern archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: getsockopt(2)
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.
Version 2 of the patch is below, the uses of getsockopt(2) by IPSEC and
SCTP expect that the optval data is copied into the kernel and back out
again by the syscall.
It looks like it was broken by this commit:
<http://mail-index.netbsd.org/source-changes/2008/08/06/msg208868.html>
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 22:24:15 -0000
@@ -1235,7 +1240,13 @@
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 (valsize > 0) {
+ error = copyin(SCARG(uap, val), sopt.sopt_data, valsize);
+ if (error)
+ goto out;
+ }
if (fp->f_flag & FNOSIGPIPE)
so->so_options |= SO_NOSIGPIPE;
Home |
Main Index |
Thread Index |
Old Index