[PATCH 3.13 252/259] tipc: clear 'next'-pointer of message fragments before reassembly
Kamal Mostafa
kamal at canonical.com
Fri Aug 8 20:41:15 UTC 2014
3.13.11.6 -stable review patch. If anyone has any objections, please let me know.
------------------
From: Jon Paul Maloy <jon.maloy at ericsson.com>
[ 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 at ericsson.com>
Signed-off-by: David S. Miller <davem at davemloft.net>
Signed-off-by: Kamal Mostafa <kamal at canonical.com>
---
net/tipc/bcast.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/tipc/bcast.c b/net/tipc/bcast.c
index 0d44025..bc1e5d6 100644
--- a/net/tipc/bcast.c
+++ b/net/tipc/bcast.c
@@ -537,6 +537,7 @@ receive:
buf = node->bclink.deferred_head;
node->bclink.deferred_head = buf->next;
+ buf->next = NULL;
node->bclink.deferred_size--;
goto receive;
}
--
1.9.1
More information about the kernel-team
mailing list