Messages in this thread Patch in this message | | | Date | Fri, 6 Nov 2015 02:19:00 +0000 | From | Al Viro <> | Subject | Re: fs: out of bounds on stack in iov_iter_advance |
| |
On Fri, Nov 06, 2015 at 01:34:02AM +0000, Al Viro wrote:
> Could you try to reproduce it with this: > > dax_io(): don't let non-error value escape via retval instead of EFAULT > > Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> > --- > diff --git a/fs/dax.c b/fs/dax.c > index a86d3cc..7b653e9 100644 > --- a/fs/dax.c > +++ b/fs/dax.c > @@ -169,8 +169,10 @@ static ssize_t dax_io(struct inode *inode, struct iov_iter *iter, > else > len = iov_iter_zero(max - pos, iter); > > - if (!len) > + if (!len) { > + retval = -EFAULT; > break; > + } > > pos += len; > addr += len; >
PS: "block, dax: fix lifetime of in-kernel dax mappings with dax_map_atomic()" Dan Williams had posted a while ago does change the things a bit, but AFAICS only in turning "return a bogus positive value" into "return an uninitialized value"; if applying that one after it, s/retval/rc/ in the above. And whether it fixes the bug Sasha had been able to trigger, the bug is real and needs fixing - it's been there since 4.0 when fs/dax.c went into the tree.
How are we going to handle that one? I can put it into mainline pull request via vfs.git, with Cc: stable, but if e.g. Jens prefers to take it via the block tree, I'll be glad to leave it for him to deal with.
| |