From: Eric Dumazet <eric.duma...@gmail.com> Date: Mon, 14 Dec 2015 14:08:53 -0800
> From: Eric Dumazet <eduma...@google.com> > > David Wilder reported crashes caused by dst reuse. > > <quote David> > I am seeing a crash on a distro V4.2.3 kernel caused by a double > release of a dst_entry. In ipv4_dst_destroy() the call to > list_empty() finds a poisoned next pointer, indicating the dst_entry > has already been removed from the list and freed. The crash occurs > 18 to 24 hours into a run of a network stress exerciser. > </quote> > > Thanks to his detailed report and analysis, we were able to understand > the core issue. > > IP early demux can associate a dst to skb, after a lookup in TCP/UDP > sockets. > > When socket cache is not properly set, we want to store into > sk->sk_dst_cache the dst for future IP early demux lookups, > by acquiring a stable refcount on the dst. > > Problem is this acquisition is simply using an atomic_inc(), > which works well, unless the dst was queued for destruction from > dst_release() noticing dst refcount went to zero, if DST_NOCACHE > was set on dst. > > We need to make sure current refcount is not zero before incrementing > it, or risk double free as David reported. > > This patch, being a stable candidate, adds two new helpers, and use > them only from IP early demux problematic paths. > > It might be possible to merge in net-next skb_dst_force() and > skb_dst_force_safe(), but I prefer having the smallest patch for stable > kernels : Maybe some skb_dst_force() callers do not expect skb->dst > can suddenly be cleared. > > Can probably be backported back to linux-3.6 kernels > > Reported-by: David J. Wilder <dwil...@us.ibm.com> > Tested-by: David J. Wilder <dwil...@us.ibm.com> > Signed-off-by: Eric Dumazet <eduma...@google.com> Applied and queued up for -stable, thanks Eric. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
