linux-kernel - Re: iov_iter

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: <20170411234820.GJ29622@ZenIV.linux.org.uk>
Date:   Wed, 12 Apr 2017 00:48:21 +0100
From:   Al Viro <viro@...IV.linux.org.uk>
To:     Dave Jones <davej@...emonkey.org.uk>,
        Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: iov_iter_pipe warning.

On Tue, Apr 11, 2017 at 07:34:37PM -0400, Dave Jones wrote:
> On Wed, Apr 12, 2017 at 12:28:42AM +0100, Al Viro wrote:
>  > On Tue, Apr 11, 2017 at 06:25:02PM -0400, Dave Jones wrote:
>  > 
>  > > ffffffff812b3130 T generic_splice_sendpage
>  > > 
>  > > This one spat out all by itself.
>  > 
>  > No need to print ->f_op for that one - can be only socket_file_ops.  Now,
>  > the address family of that socket would be interesting...
> 
> Turned out to be..
> 
>  ->splice_write = ffffffff812b2b70 sd->u.file->f_op=ffffffffa02e0980
> $ grep ffffffffa02e0980 /proc/kallsyms 
> ffffffffa02e0980 r nfs4_file_operations	[nfsv4]

Lovely...  So now we get it not only on splice to socket, but on
splice to regular file on NFS as well?  That makes lying splice_read()
more likely...

>  > Interesting...  How about
>  > 	if (res > 0 && pipe == current->splice_pipe) {
>  > 		int idx = pipe->curbuf;
>  > 		int n = pipe->nrbufs;
>  > 		size_t size = 0;
>  > 		while (n--) {
>  > 			size += pipe->bufs[idx++].len;
>  > 			if (idx == pipe->buffers)
>  > 				idx = 0;
>  > 		}
>  > 		WARN_ON(len != res);
>  > 	}
>  > just before the return in default_file_splice_read()?  WARN_ON_ONCE,
>  > perhaps, to avoid cascades...
> 
> Sure, up next. Gimme an hour, it seems to be reproducing fairly quickly
> tonight.

Makes sense - now it screams on non-empty pipe in the beginning of loop
body; originally it was only for _full_ pipe (i.e. for leftovers from
several iterations filling the entire thing up), which should've been
harder to trigger...