tipc: avoid inheriting msg_non_seq flag when message is returned
authorJon Paul Maloy <jon.maloy@ericsson.com>
Mon, 14 Aug 2017 16:28:49 +0000 (18:28 +0200)
committerDavid S. Miller <davem@davemloft.net>
Mon, 14 Aug 2017 18:20:36 +0000 (11:20 -0700)
commit59a361bc6f6e91d57f25ff0aebb0e646beb3b41d
tree51cfd0c57b5f18035dfb8bd47f894db10f374ffb
parentfed5f5718c4989a03b1b4cdc0c7f273c3c74ee9e
tipc: avoid inheriting msg_non_seq flag when message is returned

In the function msg_reverse(), we reverse the header while trying to
reuse the original buffer whenever possible. Those rejected/returned
messages are always transmitted as unicast, but the msg_non_seq field
is not explicitly set to zero as it should be.

We have seen cases where multicast senders set the message type to
"NOT dest_droppable", meaning that a multicast message shorter than
one MTU will be returned, e.g., during receive buffer overflow, by
reusing the original buffer. This has the effect that even the
'msg_non_seq' field is inadvertently inherited by the rejected message,
although it is now sent as a unicast message. This again leads the
receiving unicast link endpoint to steer the packet toward the broadcast
link receive function, where it is dropped. The affected unicast link is
thereafter (after 100 failed retransmissions) declared 'stale' and
reset.

We fix this by unconditionally setting the 'msg_non_seq' flag to zero
for all rejected/returned messages.

Reported-by: Canh Duc Luu <canh.d.luu@dektech.com.au>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
net/tipc/msg.c