On Jun 10, 2012, at 2:09 PM, Andy Polyakov wrote:

>> Hi Thomas,
>> we'll have a look at the issue. We are looking into MTU stuff anyway...
>> Best regards
>> Michael
>> On Jun 9, 2012, at 4:10 AM, Tomas Mraz via RT wrote:
>>> The getsockopt() for IP_MTU and IPV6_MTU at least on Linux returns a
>>> value of length 4. On little endian systems this is not so critical
>>> problem however on big endian 64 bit systems it means the interpretation
>>> of the returned value by the code in dgram_ctrl() is completely wrong -
> 
> Actually similar argument applies even to sockopt_len. Modulo fact that you 
> get into trouble in cases when *expected* sizeof(sockopt_len) is 8, while the 
> value is declared int. The situation is intensified by fact that in some 
> cases expected sizeof(sockopt_len) depends on compiler flags. And I'm not 
> talking about -m32 vs. -m64 compiler flags, I'm talking about flags in 64-bit 
> case [Tru64 for one if you have to know]. One way to attack the problem is 
> depicted in crypto/bio/b_sock.c:975. I mean union between unsigned int and 
> size_t, explicit zeroing of size_t member and heuristic that detects 
> big-endian trouble. Then one can declare even sockopt_val as similar union 
> and pick int or long depending on calculated sockopt_len being 4 or 8.
General comment:
Can't you use socklen_t as the type of the last argument? At least this is what
I normally use. The type of *option_value might be platform dependent, but then
we need some #ifdefs for platforms.
Regarding the IP_MTU/IPV6_MTU socket option on Linux: The Linux man page says,
that the type of the option_value is int. So I guess the bug is simply, that 
the code uses
long sockopt_val instead of int sockopt_val. All this is specific to Linux.
Robin will test, if this fixes the issue and provide a patch.

Best regards
Michael
> 
>>> you will get a bogus huge value of MTU which leads even to a segfault
>>> (fortunately without security impact) later in the DTLS code. The
>>> simplest fix would be to use int instead of long for the sockopt_val
>>> although I am not sure about the portability to other non-linux kernels.
>>> 
>>> Another problem is when s->d1->mtu is compared to dtls1_min_mtu() value
>>> in dtls1_do_write() - as signed integer value is compared to unsigned
>>> value an implicit conversion of the signed integer to unsigned value is
>>> performed and negative value (which came out of the bogus call in
>>> dgram_ctrl()) is converted to some large value and thus the comparison
>>> fails and the fallback code for choosing some safe MTU value is not
>>> invoked.
>>> -- 
>>> Tomas Mraz
>>> No matter how far down the wrong road you've gone, turn back.
>>>                                             Turkish proverb
> ______________________________________________________________________
> OpenSSL Project                                 http://www.openssl.org
> Development Mailing List                       openssl-dev@openssl.org
> Automated List Manager                           majord...@openssl.org
> 

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev@openssl.org
Automated List Manager                           majord...@openssl.org

Reply via email to