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
| ||
|
Message-ID: <57449FD2.8090808@lwfinger.net> Date: Tue, 24 May 2016 13:39:14 -0500 From: Larry Finger <Larry.Finger@...inger.net> To: Al Viro <viro@...IV.linux.org.uk> Cc: LKML <linux-kernel@...r.kernel.org> Subject: Re: Regression in 4.6.0-git - bisected to commit dd254f5a382c On 05/24/2016 11:28 AM, Al Viro wrote: > On Tue, May 24, 2016 at 11:10:09AM -0500, Larry Finger wrote: > >> For now, the following one-line hack allows my system to boot: >> >> diff --git a/fs/read_write.c b/fs/read_write.c >> index 933b53a..d5d64d9 100644 >> --- a/fs/read_write.c >> +++ b/fs/read_write.c >> @@ -721,6 +721,7 @@ static ssize_t do_loop_readv_writev(struct file *filp, >> struct iov_iter *iter, >> ret += nr; >> if (nr != iovec.iov_len) >> break; >> + nr = max_t(ssize_t, nr, 1); >> iov_iter_advance(iter, nr); >> } >> >> I have no idea what subtle bug in do_loop_readv_writev() is causing nr to be >> zero, but it seems to have been exposed by commit dd254f5a382c. > > This is definitely broken. What happens is that something calls readv() > or writev() with one of the iovecs in the middle of the vector having > zero ->iov_len. The call of iov_iter_advance(iter, 0) used to step to > the next iovec in such situation; the change in this commit leaves that to the > next primitive called, and most of the time that works just fine. > do_loop_readv_writev(), though, is picking the size to be passed to > ->write()/->read() from the current iovec, and if it had been zero from > the very beginning... guess what's going to happen. > > I'm somewhat curious about the source of that syscall - it's a good testcase > to add to ltp/xfstests, but it smells very odd for normal userland code. > It certainly needs to be fixed kernel-side, but the code issuing that is > probably worth looking into. Oddities are like mushrooms - found one, look > around for more and don't assume that the rest will be of the same species... > > I'm looking into iterate_and_advance right now; hopefully will have a sane > replacement shortly... I did a pull from mainline this morning (commit 84787c572d402) and the problem has somehow been fixed. I did not see any likely candidates in the commit messages, and I'm bisecting again to see which change did it. Larry
Powered by blists - more mailing lists