netdev - Re: v3 [PATCH 1/1] dccp: Process incoming Change feature-negotiation options

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20080904045136.GA3768@gerrit.erg.abdn.ac.uk>
Date:	Thu, 4 Sep 2008 06:51:36 +0200
From:	Gerrit Renker <gerrit@....abdn.ac.uk>
To:	Wei Yongjun <yjwei@...fujitsu.com>
Cc:	dccp@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: v3 [PATCH 1/1] dccp: Process incoming Change
	feature-negotiation options

>>>> +	/*
>>>> +	 *	Unidirectional/simultaneous negotiation of SP features (6.3.1)
>>>> +	 */
>>>> +	entry = dccp_feat_list_lookup(fn, feat, local);
>>>> +	if (entry == NULL) {
>>>> +		if (!dccp_feat_sp_list_ok(feat, val, len))
>>>> +			goto unknown_feature_or_value;
>>>>         
>>> Check for sp feat list should before code "entry =   
>>> dccp_feat_list_lookup(fn, feat, local);",
>>> here only check for features not register by local endpoint, if the   
>>> feature is registed, the validity check is missing?
>>>
>>>     
>> 
>> No, in this case the validity check is performed already as part of the socket
>> registration routines - which in turn end up calling dccp_feat_sp_list_ok.
>> If a user tries to register invalid SP values on the socket, the attempt
>> will fail with EINVAL. If the user does not register values, the feature
>> defaults (6.4) are used, which are valid by definition.
>> The host is conservative in what it allows to send out.
>>   
>
> The socket registration routines check the feature values local set, but  
> this place is check the features we *received* from other endpoints.
>
> I agree with you here do not need chec as your other mail said:
> RFC4340 6.6.8
> Note that server-priority features do not have value limitations, since
> unknown values are handled as a matter of course.
>
> May be this check "if (!dccp_feat_sp_list_ok(feat, val, len))" is too  
> strictly for known sp features but not registed by socket.
>
Yes that is possible, since in this case the host has not registered any
preferences, which means that either
 * only the first value is used
 * or negotiation is done against the default value.

Checking only the first value also gives a bit more robustness. I have
changed this and will send the full diff after testing and uploading. 
Thanks again.
--
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