linux-kernel - Re: Bug 4.1.16: self-detected stall in net/unix/?

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:	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.