tipc: clear 'next'-pointer of message fragments before reassembly
authorJon Paul Maloy <jon.maloy@ericsson.com>
Fri, 11 Jul 2014 12:45:27 +0000 (08:45 -0400)
committerDavid S. Miller <davem@davemloft.net>
Fri, 11 Jul 2014 22:02:10 +0000 (15:02 -0700)
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>
net/tipc/bcast.c

index 26631679a1faa4bb7b8c720dda1e48b5c68ab40e..55c6c9d3e1ceee905bd25ce09d4c8bd7c41a3412 100644 (file)
@@ -559,6 +559,7 @@ receive:
 
                buf = node->bclink.deferred_head;
                node->bclink.deferred_head = buf->next;
+               buf->next = NULL;
                node->bclink.deferred_size--;
                goto receive;
        }