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
