af_rxrpc: Fix UDP MTU calculation from ICMP_FRAG_NEEDED
authorDavid Howells <dhowells@redhat.com>
Fri, 14 Feb 2014 12:02:41 +0000 (12:02 +0000)
committerDavid Howells <dhowells@redhat.com>
Wed, 26 Feb 2014 17:25:01 +0000 (17:25 +0000)
commit6c9a2d3202973a0266beabc5274c3e67dad5db96
tree15f7e49861faec55d167131093c68e8e0bd40d13
parentb6f3a40cb70fa53a5160b8f061ff219b00992626
af_rxrpc: Fix UDP MTU calculation from ICMP_FRAG_NEEDED

AF_RXRPC sends UDP packets with the "Don't Fragment" bit set in an attempt to
determine the maximum packet size between the local socket and the peer by
invoking the generation of ICMP_FRAG_NEEDED packets.

Once a packet is sent with the "Don't Fragment" bit set, it is then
inconvenient to break it up as that requires recalculating all the rxrpc serial
and sequence numbers and reencrypting all the fragments, so we switch off the
"Don't Fragment" service temporarily and send the bounced packet again.  Future
packets then use the new MTU.

That's all fine.  The problem lies in rxrpc_UDP_error_report() where the code
that deals with ICMP_FRAG_NEEDED packets lives.  Packets of this type have a
field (ee_info) to indicate the maximum packet size at the reporting node - but
sometimes ee_info isn't filled in and is just left as 0 and the code must allow
for this.

When ee_info is 0, the code should take the MTU size we're currently using and
reduce it for the next packet we want to send.  However, it takes ee_info
(which is known to be 0) and tries to reduce that instead.

This was discovered by Coverity.

Reported-by: Dave Jones <davej@redhat.com>
Signed-off-by: David Howells <dhowells@redhat.com>
net/rxrpc/ar-error.c