lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6033284.KrP4yu8ukf@hector>
Date:	Wed, 09 Nov 2011 17:00:48 +0200
From:	Rémi Denis-Courmont 
	<remi.denis-courmont@...ia.com>
To:	ext Hemant Vilas RAMDASI <hemant.ramdasi@...ricsson.com>
Cc:	netdev@...r.kernel.org,
	Dinesh Kumar Sharma <dinesh.sharma@...ricsson.com>
Subject: Re: [PATCH] Phonet: set the pipe handle using setsockopt

Inline...

Le Mercredi 9 Novembre 2011 16:50:53 ext Hemant Vilas RAMDASI a écrit :
> @@ -863,9 +902,27 @@ static int pep_sock_connect(struct sock *sk, struct
> sockaddr *addr, int len) int err;
>  	u8 data[4] = { 0 /* sub-blocks */, PAD, PAD, PAD };
> 
> -	pn->pipe_handle = 1; /* anything but INVALID_HANDLE */
> +	if (pn->pipe_handle == PN_PIPE_INVALID_HANDLE)
> +		pn->pipe_handle = 1; /* anything but INVALID_HANDLE */
> +
>  	err = pipe_handler_request(sk, PNS_PEP_CONNECT_REQ,
> -					PN_PIPE_ENABLE, data, 4);
> +					pn->init_enable, data, 4);
> +
> +	if (err) {
> +		pn->pipe_handle = PN_PIPE_INVALID_HANDLE;

This undoes the setsockopt() silently. I'm not sure you intend this?

> +		return err;
> +	}
> +	sk->sk_state = TCP_SYN_SENT;
> +	return 0;
> +}
> +
> +static int pep_sock_enable(struct sock *sk, struct sockaddr *addr, int len)
> +{
> +	struct pep_sock *pn = pep_sk(sk);
> +	int err;
> +
> +	err = pipe_handler_request(sk, PNS_PEP_ENABLE_REQ, PAD,
> +				NULL, 0);
>  	if (err) {
>  		pn->pipe_handle = PN_PIPE_INVALID_HANDLE;
>  		return err;
> @@ -959,6 +1016,24 @@ static int pep_setsockopt(struct sock *sk, int level,
> int optname, }
>  		goto out_norel;
> 
> +	case PNPIPE_HANDLE:
> +		if (val)
> +			pn->pipe_handle = val;
> +		else
> +			err = -EINVAL;
> +		break;

Why is zero a special case? What about out-of-range values?

> +
> +	case PNPIPE_ENABLE:
> +		err = pep_sock_enable(sk, NULL, 0);
> +		break;

This is reintroducing the problems with the older code. As far as I know,  
setsockopt() needs to be idempotent, which this does not seem to be?

> +
> +	case PNPIPE_INITSTATE:
> +		if ((val == PN_PIPE_DISABLE) || (val == PN_PIPE_ENABLE))
> +			pn->init_enable = val;
> +		else
> +			err = -EINVAL;
> +		break;

It looks like there is no use-case for init-enabled pipes then, right? How 
about dropping this extra bit of code and assuming connect()ed pipes are 
always init-disabled?

> +
>  	default:
>  		err = -ENOPROTOOPT;
>  	}
> @@ -994,6 +1069,13 @@ static int pep_getsockopt(struct sock *sk, int level,
> int optname, return -EINVAL;
>  		break;
> 
> +	case PNPIPE_ENABLE:
> +		if (sk->sk_state != TCP_ESTABLISHED)
> +			return -EINVAL;
> +		else
> +			val = 1;
> +		break;
> +
>  	default:
>  		return -ENOPROTOOPT;
>  	}
-- 
Rémi Denis-Courmont
http://www.remlab.net/

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ