summaryrefslogtreecommitdiffstats
path: root/net
diff options
context:
space:
mode:
authorJon Paul Maloy <jon.maloy@ericsson.com>2014-07-11 08:45:27 -0400
committerDavid S. Miller <davem@davemloft.net>2014-07-11 15:02:10 -0700
commit999417549c16dd0e3a382aa9f6ae61688db03181 (patch)
treebc6c9abeee8bf65d9785cc9b867e39aab7754729 /net
parenta91d45f1a343188793d6f2bdf1a72c64015a8255 (diff)
downloadop-kernel-dev-999417549c16dd0e3a382aa9f6ae61688db03181.zip
op-kernel-dev-999417549c16dd0e3a382aa9f6ae61688db03181.tar.gz
tipc: clear 'next'-pointer of message fragments before reassembly
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>
Diffstat (limited to 'net')
-rw-r--r--net/tipc/bcast.c1
1 files changed, 1 insertions, 0 deletions
diff --git a/net/tipc/bcast.c b/net/tipc/bcast.c
index 2663167..55c6c9d 100644
--- a/net/tipc/bcast.c
+++ b/net/tipc/bcast.c
@@ -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;
}
OpenPOWER on IntegriCloud