lkml.org 
[lkml]   [2014]   [Jul]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    From
    Subject[PATCH 3.4 11/23] tipc: clear next-pointer of message fragments before reassembly
    Date
    3.4-stable review patch.  If anyone has any objections, please let me know.

    ------------------

    From: Jon Paul Maloy <jon.maloy@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@ericsson.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    ---
    net/tipc/bcast.c | 1 +
    1 file changed, 1 insertion(+)

    --- a/net/tipc/bcast.c
    +++ b/net/tipc/bcast.c
    @@ -541,6 +541,7 @@ receive:

    buf = node->bclink.deferred_head;
    node->bclink.deferred_head = buf->next;
    + buf->next = NULL;
    node->bclink.deferred_size--;
    goto receive;
    }



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