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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20190816.162737.128286385440292449.davem@davemloft.net>
Date:   Fri, 16 Aug 2019 16:27:37 -0700 (PDT)
From:   David Miller <davem@...emloft.net>
To:     tuong.t.lien@...tech.com.au
Cc:     jon.maloy@...csson.com, maloy@...jonn.com, ying.xue@...driver.com,
        netdev@...r.kernel.org, tipc-discussion@...ts.sourceforge.net
Subject: Re: [net] tipc: fix false detection of retransmit failures

From: Tuong Lien <tuong.t.lien@...tech.com.au>
Date: Thu, 15 Aug 2019 10:24:08 +0700

> This commit eliminates the use of the link 'stale_limit' & 'prev_from'
> (besides the already removed - 'stale_cnt') variables in the detection
> of repeated retransmit failures as there is no proper way to initialize
> them to avoid a false detection, i.e. it is not really a retransmission
> failure but due to a garbage values in the variables.
> 
> Instead, a jiffies variable will be added to individual skbs (like the
> way we restrict the skb retransmissions) in order to mark the first skb
> retransmit time. Later on, at the next retransmissions, the timestamp
> will be checked to see if the skb in the link transmq is "too stale",
> that is, the link tolerance time has passed, so that a link reset will
> be ordered. Note, just checking on the first skb in the queue is fine
> enough since it must be the oldest one.
> A counter is also added to keep track the actual skb retransmissions'
> number for later checking when the failure happens.
> 
> The downside of this approach is that the skb->cb[] buffer is about to
> be exhausted, however it is always able to allocate another memory area
> and keep a reference to it when needed.
> 
> Fixes: 77cf8edbc0e7 ("tipc: simplify stale link failure criteria")
> Reported-by: Hoang Le <hoang.h.le@...tech.com.au>
> Acked-by: Ying Xue <ying.xue@...driver.com>
> Acked-by: Jon Maloy <jon.maloy@...csson.com>
> Signed-off-by: Tuong Lien <tuong.t.lien@...tech.com.au>

Applied, thank you.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ