[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87mvr7jfor.fsf@doppelsaurus.mobileactivedefense.com>
Date: Thu, 11 Feb 2016 17:54:28 +0000
From: Rainer Weikusat <rweikusat@...ileactivedefense.com>
To: Ben Hutchings <ben@...adent.org.uk>
Cc: Rainer Weikusat <rweikusat@...ileactivedefense.com>,
Philipp Hahn <pmhahn@...ahn.de>,
Hannes Frederic Sowa <hannes@...essinduktion.org>,
Sasha Levin <sasha.levin@...cle.com>,
"David S. Miller" <davem@...emloft.net>,
linux-kernel@...r.kernel.org, Karolin Seeger <kseeger@...ba.org>,
Jason Baron <jbaron@...mai.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Arvid Requate <requate@...vention.de>,
Stefan Gohmann <gohmann@...vention.de>
Subject: Re: Bug 4.1.16: self-detected stall in net/unix/?
Rainer Weikusat <rw@...pelsaurus.mobileactivedefense.com> writes:
[...]
> This means it only gets locked if unix_peer(other) != sk and this cannot
> happen if other == sk and unix_peer(sk) == other, however, the 2nd
> condition isn't guaranteed: other might indeed be == sk and not the peer
> of it because someone could be using _sendmsg to send a message via a
> socket to an address bound to the same socket. In this case, other was
> found via
A second way to hits this (probably somewhat difficult to trigger in
practice): sk happened to be connected to itself by the time the
unix_peer_get(sk) was executed but was disconnected before the
unix_state_lock(other) below.
Powered by blists - more mailing lists