linux-kernel - 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] [day] [month] [year] [list]

Message-ID: <87ziwizrz0.fsf@doppelsaurus.mobileactivedefense.com>
Date:	Wed, 06 Jan 2016 14:45:55 +0000
From:	Rainer Weikusat <rweikusat@...ileactivedefense.com>
To:	Hannes Frederic Sowa <hannes@...essinduktion.org>
Cc:	Rainer Weikusat <rweikusat@...ileactivedefense.com>,
	David Miller <davem@...emloft.net>, 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

Hannes Frederic Sowa <hannes@...essinduktion.org> writes:
> On Sun, Jan 3, 2016, at 19:03, Rainer Weikusat wrote:

[reorder i_mutex and readlock locking]

> I was concerned because of the comment in skb_socket_splice:
>
>         /* Drop the socket lock, otherwise we have reverse
>          * locking dependencies between sk_lock and i_mutex
>          * here as compared to sendfile(). We enter here
>          * with the socket lock held, and splice_to_pipe() will
>          * grab the pipe inode lock. For sendfile() emulation,
>          * we call into ->sendpage() with the i_mutex lock held
>          * and networking will grab the socket lock.
>          */

AFAICT, this comment is "a bit misleading": sendfile (from file to
socket) is internally implemented as 'splice from file to pipe' +
'splice from pipe to socket'. The later acquires the pipe lock of the
pipe and then invokes the sendpage method of the socket which acquires
the appropiate socket lock (for an AF_UNIX socket, it's
u->readlock). But 'pipe lock' and 'i_mutex' are two completely
different things: The former is the mutex in a struct pipe_inode_info
(pipe_fs_u.h), the latter is the i_mutex in a struct inode (fs.h).

"Code explains comment" :-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/