netdev - Re: [net 1/1] tipc: fix link re-establish failure

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Sun, 11 Nov 2018 10:04:29 -0800 (PST)
From:   David Miller <davem@...emloft.net>
To:     donmalo99@...il.com
Cc:     netdev@...r.kernel.org, gordan.mihaljevic@...tech.com.au,
        tung.q.nguyen@...tech.com.au, hoang.h.le@...tech.com.au,
        jon.maloy@...csson.com, maloy@...jonn.com, xinl@...hat.com,
        ying.xue@...driver.com, tipc-discussion@...ts.sourceforge.net
Subject: Re: [net 1/1] tipc: fix link re-establish failure

From: Jon Maloy <donmalo99@...il.com>
Date: Sat, 10 Nov 2018 17:30:24 -0500

> When a link failure is detected locally, the link is reset, the flag
> link->in_session is set to false, and a RESET_MSG with the 'stopping'
> bit set is sent to the peer.
> 
> The purpose of this bit is to inform the peer that this endpoint just
> is going down, and that the peer should handle the reception of this
> particular RESET message as a local failure. This forces the peer to
> accept another RESET or ACTIVATE message from this endpoint before it
> can re-establish the link. This again is necessary to ensure that
> link session numbers are properly exchanged before the link comes up
> again.
> 
> If a failure is detected locally at the same time at the peer endpoint
> this will do the same, which is also a correct behavior.
> 
> However, when receiving such messages, the endpoints will not
> distinguish between 'stopping' RESETs and ordinary ones when it comes
> to updating session numbers. Both endpoints will copy the received
> session number and set their 'in_session' flags to true at the
> reception, while they are still expecting another RESET from the
> peer before they can go ahead and re-establish. This is contradictory,
> since, after applying the validation check referred to below, the
> 'in_session' flag will cause rejection of all such messages, and the
> link will never come up again.
> 
> We now fix this by not only handling received RESET/STOPPING messages
> as a local failure, but also by omitting to set a new session number
> and the 'in_session' flag in such cases.
> 
> Fixes: 7ea817f4e832 ("tipc: check session number before accepting link protocol messages")
> Signed-off-by: Jon Maloy <jon.maloy@...csson.com>

Applied and queued up for -stable.