lkml.org 
[lkml]   [2014]   [Jul]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    From
    Subject[PATCH 3.12 52/94] tipc: clear 'next'-pointer of message fragments before reassembly
    Date
    From: Jon Paul Maloy <jon.maloy@ericsson.com>

    3.12-stable review patch. If anyone has any objections, please let me know.

    ===============

    [ 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: Jiri Slaby <jslaby@suse.cz>
    ---
    net/tipc/bcast.c | 1 +
    1 file changed, 1 insertion(+)

    diff --git a/net/tipc/bcast.c b/net/tipc/bcast.c
    index 716de1ac6cb5..6ef89256b2fb 100644
    --- a/net/tipc/bcast.c
    +++ b/net/tipc/bcast.c
    @@ -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;
    }
    --
    2.0.1


    \
     
     \ /
      Last update: 2014-07-30 15:21    [W:6.021 / U:0.032 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site