linux-kernel - Re: 4.9.0 regression in pipe-backed iov

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:   Sat, 14 Jan 2017 01:43:40 +0000
From:   Al Viro <viro@...IV.linux.org.uk>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     "Alan J. Wylie" <alan@...ie.me.uk>,
        Thorsten Leemhuis <regressions@...mhuis.info>,
        linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: 4.9.0 regression in pipe-backed iov_iter with systemd-nspawn

On Sat, Jan 14, 2017 at 01:24:28AM +0000, Al Viro wrote:
> On Fri, Jan 13, 2017 at 04:59:37PM -0800, Linus Torvalds wrote:
> 
> > EXCEPT.
> > 
> > I don't think "i->iov_offset" is actually correct. If you truncated
> > the whole thing, you should have cleared iov_offset too, and that
> > never happened. So truncating everything will not empty the buffers
> > for us, we'll still get to that "if (off)" case and have nrbufs=1.
> > 
> > So I'd expect something like
> > 
> >     if (!size)
> >         i->iov_offset = 0;
> > 
> > in pipe_advance(), in order to really free all buffers for that case. No?
> 
> Why would advance by 0 change ->iov_offset here?
> 
> > Or is there some guarantee that iov_offset was already zero there? I
> > don't see it, but I'm batting zero on this code...
> 
> It was zero initially (see iov_iter_pipe()).  It was not affected by
> iov_iter_get_pages() and friends.  If there was copy_to_iter/zero_iter/
> copy_page_to_iter for any non-zero amount of data, then it's _not_ zero and
> should bloody well stay such.

PS: note that after copy_page_to_iter()/copy_to_iter()/zero_iter() we have
->idx pointing to the last used buffer and ->iov_offset pointing to the end
of data in it, even if it's certain to be full and the next piece written
will go into the next buffer.  The only situation where we have zero
->iov_offset is when no copying had been done at all (via that iov_iter,
that is).  In that case ->idx points to the empty buffer.

If you start with empty pipe and copy_to_pipe() until it fills, you'll have
(assuming e.g. 4K pages and ->curbuf == 3 in the beginning)
	->idx == 3, ->iov_offset == 0 initially
	->idx == 3, ->iov_offset == 4096 after 4096 bytes copied
	->idx == 4, ->iov_offset == 1 after 4097 bytes
...
	->idx == 2, ->iov_offset == 4096 by the end of it.

That's what this "correction" is about...