[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <1405082727-14546-1-git-send-email-jon.maloy@ericsson.com>
Date: Fri, 11 Jul 2014 08:45:27 -0400
From: Jon Maloy <jon.maloy@...csson.com>
To: davem@...emloft.net
Cc: netdev@...r.kernel.org,
Paul Gortmaker <paul.gortmaker@...driver.com>,
erik.hugne@...csson.com, ying.xue@...driver.com, maloy@...jonn.com,
tipc-discussion@...ts.sourceforge.net,
Jon Maloy <jon.maloy@...csson.com>
Subject: [PATCH net 1/1] 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@...csson.com>
---
net/tipc/bcast.c | 1 +
1 file changed, 1 insertion(+)
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;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists