netdev - splice-bind deadlock (was: [PATCH] af_unix: Revert 'lock

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]

Date:	Fri, 18 Dec 2015 16:04:09 +0000
From:	Rainer Weikusat <rweikusat@...ileactivedefense.com>
To:	Hannes Frederic Sowa <hannes@...essinduktion.org>
Cc:	David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org, Al Viro <viro@...IV.linux.org.uk>
Subject: splice-bind deadlock (was: [PATCH] af_unix: Revert 'lock_interruptible' in stream receive code)

Rainer Weikusat <rw@...pelsaurus.mobileactivedefense.com> writes:
> Hannes Frederic Sowa <hannes@...essinduktion.org> writes:
>
> [...]
>
>> There is still a deadlock lingering around
>
> [...]
>
>> http://lists.openwall.net/netdev/2015/11/10/4

[...]

> 	(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.
	[from the page]

[...]

> Given
> 	a/b	- acquire a block b (eg, get read lock on superblock
>                   rwsem)
>
> 	b/a	- acquire b block a
>
>         c	- u->readlock
>
>         d	- pipe lock
>
> 	[*y]   - blocks waiting for y
>
>         
> B	a/b
>
> C	b/a[*B]
>
> A	c
> A	a/b[*C]
>
> D	d
> D	c[*A]
>
> B	d[*D]

Some more explanations on this: There two groups of three in the above
(X <- Y supposed to mean 'Y waits for X'), B <- C <- A and A <- D <-
B. 'B blocking C blocking A' is really the same as if B was holding an
abstract mutex m0 A wants. Likewise, A <- D <- B is equivalent to A
holding an abstract mutex m1 B wants. Conceptually, there are two
threads and two locks here,

B: acquires m0 then m1
A: acquires m1 then m0

and because of the conflicting  locking orders, the whole
shoggoth deadlocks sooner or later (Fhtagn!).

The obvious idea to fix this is to reverse either A or B. I think A
should be reversed because that's probably easier (unless there's some
technical problem with that I don't yet know of) and because this avoids
a situation where some other thread which wants the readlock mutex has to
wait until some completeld unrelated filesystem operations have
completed.

But theory only gets one so far and it would be good if someone capable
of reproducing the problem tested this.
--
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