From: Marcelo Ricardo Leitner
> Sent: 14 July 2015 18:13
> SCTP has this operation to peel off associations from a given socket and
> create a new socket using this association. We currently have two ways
> to use this operation:
> - via getsockopt(), on which it will also create and return a file
> descriptor for this new socket
> - via sctp_do_peeloff(), which is for kernel only
>
> The caveat with using sctp_do_peeloff() directly is that it creates a
> dependency to SCTP module, while all other operations are handled via
> kernel_{socket,sendmsg,getsockopt...}() interface. This causes the
> kernel to load SCTP module even when it's not really used.
>
> This patch then creates a new sockopt that is to be used only by kernel
> users of this protocol. This new sockopt will not allocate a file
> descriptor but instead just return the socket pointer directly.
>
> Kernel users are actually identified by if the parent socket has or not
> a fd attached to it. If not, it's a kernel a user.
>
> If called by an user application, it will just return -EPERM.
>
> Even though it's not intended for user applications, it's listed under
> uapi header. That's because hidding this wouldn't add any extra security
> and to keep the sockopt list in one place, so it's easy to check
> available numbers to use.
>
> Signed-off-by: Marcelo Ricardo Leitner <marcelo.leit...@gmail.com>
...
> +static int sctp_getsockopt_peeloff_kernel(struct sock *sk, int len,
> + char __user *optval, int __user
> *optlen)
> +{
> + sctp_peeloff_kernel_arg_t peeloff;
> + struct socket *newsock;
> + int retval = 0;
> +
> + /* We only allow this operation if parent socket also hadn't a
> + * file descriptor allocated to it, mainly as a way to make sure
> + * that this is really a kernel socket.
> + */
> + if (sk->sk_socket->file)
> + return -EPERM;
> +
> + if (len < sizeof(sctp_peeloff_kernel_arg_t))
> + return -EINVAL;
> + len = sizeof(sctp_peeloff_kernel_arg_t);
> + if (copy_from_user(&peeloff, optval, len))
> + return -EFAULT;
You can't need copy_from_user() here, the buffer would surely be kernel.
David
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
