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 -
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
