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] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 11 Jun 2014 18:55:20 -0700 (PDT)
From:	dormando <dormando@...ia.net>
To:	Eric Dumazet <eric.dumazet@...il.com>
cc:	Alexey Preobrazhensky <preobr@...gle.com>,
	Steffen Klassert <steffen.klassert@...unet.com>,
	David Miller <davem@...emloft.net>, paulmck@...ux.vnet.ibm.com,
	netdev@...r.kernel.org, Kostya Serebryany <kcc@...gle.com>,
	Dmitry Vyukov <dvyukov@...gle.com>,
	Lars Bull <larsbull@...gle.com>,
	Eric Dumazet <edumazet@...gle.com>,
	Bruce Curtis <brutus@...gle.com>,
	Maciej Żenczykowski <maze@...gle.com>,
	Alexei Starovoitov <alexei.starovoitov@...il.com>
Subject: Re: [PATCH] ipv4: fix a race in ip4_datagram_release_cb()

On Wed, 11 Jun 2014, Eric Dumazet wrote:

> On Wed, 2014-06-11 at 05:41 -0700, Eric Dumazet wrote:
>
> >
> > OK then we probably have another bug in UDP, which is that we call
> > sk_dst_set(sk, dst_clone(&rt->dst)); with a dst having DST_NOCACHE set
> >
> > Its a problem, because sk_dst_get() cannot deal safely with such dst.
>
> You could try this in top of other patches.
>
> diff --git a/include/net/sock.h b/include/net/sock.h
> index 21569cf456ed..427ac7cc50fc 100644
> --- a/include/net/sock.h
> +++ b/include/net/sock.h
> @@ -1728,8 +1728,8 @@ sk_dst_get(struct sock *sk)
>
>  	rcu_read_lock();
>  	dst = rcu_dereference(sk->sk_dst_cache);
> -	if (dst)
> -		dst_hold(dst);
> +	if (dst && !atomic_inc_not_zero(&dst->__refcnt))
> +		dst = NULL;
>  	rcu_read_unlock();
>  	return dst;
>  }
>
>
>

I sent the udpkill utility in an off-list mail (in case that got binned by
anyone).

Just threw this patch on top of the other two, on 3.10.42. udpkill's been
running for an hour without fault. I've just put traffic back onto the
machine am leaving udpkill enabled for a while longer.

So, this is an improvement :)

I have exactly one machine which (for whatever lucky reason) is really
prone to hitting this problem without needing udpkill. It'll take a few
days to get it going there though. I've not been able to reproduce the
crash from other angles yet.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists