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]

Date:   Tue, 11 Apr 2017 16:53:36 -0400
From:   Dave Jones <davej@...emonkey.org.uk>
To:     Al Viro <viro@...IV.linux.org.uk>
Cc:     Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: iov_iter_pipe warning.

On Tue, Apr 11, 2017 at 04:28:39AM +0100, Al Viro wrote:
 > On Mon, Apr 10, 2017 at 11:05:32PM -0400, Dave Jones wrote:
 > > On Tue, Apr 11, 2017 at 01:22:15AM +0100, Al Viro wrote:
 > > 
 > >  > 	* in do_splice_to(): WARN_ON(pipe->nrbufs == pipe->buffers)
 > > 
 > > Hit this one.
 > 
 > But not WARN_ON(pipe->nrbufs) in its caller *or* WARN_ON(!pipe->buffers)
 > in do_splice_to() itself?
 > 
 > How the devil can that be possible?
 > 
 > Again, to make sure we are on the same page: in
 > 	if (WARN_ON(pipe->nrbufs)) {
 > 		printk(KERN_ERR "->splice_write = %p",
 > 			sd->u.file->f_op->splice_write);
 > 	}
 >         while (len) {
 >                 size_t read_len;
 >                 loff_t pos = sd->pos, prev_pos = pos;
 > 
 >                 ret = do_splice_to(in, &pos, pipe, len, flags);
 > 		...
 > 		... (not a single continue in sight)
 > 		...
 > 		if (WARN_ON(pipe->nrbufs)) {
 > 			printk(KERN_ERR "->splice_write = %p",
 > 				sd->u.file->f_op->splice_write);
 > 		}
 > 	}

Ah, missed adding this 2nd WARN_ON.

 > neither of those WARN_ON() triggers.  In do_splice_to()
 > 	WARN_ON(pipe->nrbufs == pipe->buffers);
 > does trigger, but
 > 	WARN_ON(!pipe->buffers);
 > does not.  And pipe is equal to current->splice_pipe, so nobody else could
 > see it, let alone be messing with it.
 > 
 > How can that be possible?  Non-triggering WARN_ON() in caller of do_splice_to()
 > mean that pipe->nrbufs is zero.  Triggering WARN_ON() in do_splice_to() means
 > that it's equal to pipe->buffers, but WARN_ON(!pipe->buffers) manages to avoid
 > being triggered?  Can you confirm all that?
 
asides from above, yeah, same.

 > Because if that's the case,
 > the next possibility is random memory corruption and/or pipe_info dangling
 > pointers/use-after-free/etc.

I've been tied up with other stuff today, so while I was preoccupied, I
did a run with KASAN to see if anything fell out.  That seems to slow
things down enough that I don't trigger anything. Been running all day
without incident.

I'll turn it back off, and retry with the missing WARN from above added.

	Dave