netdev - Re: [PATCH] af_unix: Fix splice-bind deadlock

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]

Message-Id: <20160104.232328.2119620215364418586.davem@davemloft.net>
Date:	Mon, 04 Jan 2016 23:23:28 -0500 (EST)
From:	David Miller <davem@...emloft.net>
To:	rweikusat@...ileactivedefense.com
Cc:	dvyukov@...gle.com, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org, viro@...IV.linux.org.uk
Subject: Re: [PATCH] af_unix: Fix splice-bind deadlock

From: Rainer Weikusat <rweikusat@...ileactivedefense.com>
Date: Sun, 03 Jan 2016 18:56:38 +0000

> On 2015/11/06, Dmitry Vyukov reported a deadlock involving the splice
> system call and AF_UNIX sockets, 
> 
> http://lists.openwall.net/netdev/2015/11/06/24
> 
> The situation was analyzed as
> 
> (a while ago) A: socketpair()
> B: splice() from a pipe to /mnt/regular_file
> 	does sb_start_write() on /mnt
> C: try to freeze /mnt
> 	wait for B to finish with /mnt
> A: bind() try to bind our socket to /mnt/new_socket_name
> 	lock our socket, see it not bound yet
> 	decide that it needs to create something in /mnt
> 	try to do sb_start_write() on /mnt, block (it's
> 	waiting for C).
> D: splice() from the same pipe to our socket
> 	lock the pipe, see that socket is connected
> 	try to lock the socket, block waiting for A
> B:	get around to actually feeding a chunk from
> 	pipe to file, try to lock the pipe.  Deadlock.
> 
> on 2015/11/10 by Al Viro,
> 
> http://lists.openwall.net/netdev/2015/11/10/4
> 
> The patch fixes this by removing the kern_path_create related code from
> unix_mknod and executing it as part of unix_bind prior acquiring the
> readlock of the socket in question. This means that A (as used above)
> will sb_start_write on /mnt before it acquires the readlock, hence, it
> won't indirectly block B which first did a sb_start_write and then
> waited for a thread trying to acquire the readlock. Consequently, A
> being blocked by C waiting for B won't cause a deadlock anymore
> (effectively, both A and B acquire two locks in opposite order in the
> situation described above).
> 
> Dmitry Vyukov(<dvyukov@...gle.com>) tested the original patch.
> 
> Signed-off-by: Rainer Weikusat <rweikusat@...ileactivedefense.com>

Applied and queued up for -stable, thanks Rainer.
--
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