netdev - Re: [PATCH] af_packet: Raw socket destruction warning fix

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]

Message-ID: <1455116161.19473.4.camel@edumazet-glaptop2.roam.corp.google.com>
Date:	Wed, 10 Feb 2016 06:56:01 -0800
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	v.narang@...sung.com
Cc:	Daniel Borkmann <daniel@...earbox.net>,
	Maninder Singh <maninder1.s@...sung.com>,
	"davem@...emloft.net" <davem@...emloft.net>,
	"willemb@...gle.com" <willemb@...gle.com>,
	"edumazet@...gle.com" <edumazet@...gle.com>,
	"eyal.birger@...il.com" <eyal.birger@...il.com>,
	"tklauser@...tanz.ch" <tklauser@...tanz.ch>,
	"fruggeri@...stanetworks.com" <fruggeri@...stanetworks.com>,
	"dwmw2@...radead.org" <dwmw2@...radead.org>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	PANKAJ MISHRA <pankaj.m@...sung.com>,
	Geon-ho Kim <gh007.kim@...sung.com>,
	Hak-Bong Lee <hakbong5.lee@...sung.com>,
	"ajeet.y@...sung.com" <ajeet.y@...sung.com>,
	AKHILESH KUMAR <akhilesh.k@...sung.com>,
	AMIT NAGAL <amit.nagal@...sung.com>
Subject: Re: [PATCH] af_packet: Raw socket destruction warning fix

On Wed, 2016-02-10 at 12:43 +0000, Vaneet Narang wrote:
> Hi,
> 
> >What driver are you using (is that in-tree)? Can you reproduce the same issue
> >with a latest -net kernel, for example (or, a 'reasonably' recent one like 4.3 or
> >4.4)? There has been quite a bit of changes in err queue handling (which also
> >accounts rmem) as well. How reliably can you trigger the issue? Does it trigger
> >with a completely different in-tree network driver as well with your tests? Would
> >be useful to track/debug sk_rmem_alloc increases/decreases to see from which path
> >new rmem is being charged in the time between packet_release() and packet_sock_destruct()
> >for that socket ...
> >
> It seems race condition to us between packet_rcv and packet_close, we have tried to reproduce
> this issue by adding delay in skb_set_owner_r and issue gets reproduced quite frequently. 
> we have added some traces and on analyzing we have realised following possible race condition.



Even if you add a delay in skb_set_owner_r(), this should not allow the
dismantle phase to complete, since at least one cpu is still in a
rcu_read_lock() section.

synchronize_rcu() must complete only when all cpus pass an rcu quiescent
point.

packet_close() should certainly not be called while another cpu is still
in the middle of packet_rcv()

Your patch does not address the root cause.