tipc: clear 'next'-pointer of message fragments before reassembly

[ Upstream commit 999417549c16dd0e3a382aa9f6ae61688db03181 ]

If the 'next' pointer of the last fragment buffer in a message is not
zeroed before reassembly, we risk ending up with a corrupt message,
since the reassembly function itself isn't doing this.

Currently, when a buffer is retrieved from the deferred queue of the
broadcast link, the next pointer is not cleared, with the result as
described above.

This commit corrects this, and thereby fixes a bug that may occur when
long broadcast messages are transmitted across dual interfaces. The bug
has been present since 40ba3cdf542a469aaa9083fa041656e59b109b90 ("tipc:
message reassembly using fragment chain")

This commit should be applied to both net and net-next.

Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

This commit is contained in:

Jon Paul Maloy

2014-07-11 08:45:27 -04:00

committed by

Greg Kroah-Hartman

parent c771cc33f9

commit 6000843594

1 changed files with 1 additions and 0 deletions

									
										net/tipc/bcast.c
									
		+1
		
												View File
												
				@@ -531,6 +531,7 @@ receive:

						buf = node->bclink.deferred_head;

						node->bclink.deferred_head = buf->next;

						buf->next = NULL;

						node->bclink.deferred_size--;

						goto receive;

					}