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: <20160524234133.GA14480@ZenIV.linux.org.uk> Date: Wed, 25 May 2016 00:41:33 +0100 From: Al Viro <viro@...IV.linux.org.uk> To: Matthew McClintock <mmcclint@...eaurora.org> Cc: Larry Finger <Larry.Finger@...inger.net>, LKML <linux-kernel@...r.kernel.org> Subject: Re: Regression in 4.6.0-git - bisected to commit dd254f5a382c On Tue, May 24, 2016 at 05:31:51PM -0500, Matthew McClintock wrote: > > > On May 24, 2016, at 2:36 PM, Larry Finger <Larry.Finger@...inger.net> wrote: > > > > On 05/24/2016 02:25 PM, Matthew McClintock wrote: > >> On May 24, 2016, at 2:16 PM, Larry Finger <Larry.Finger@...inger.net> wrote: > >>> > >>> On 05/24/2016 02:13 PM, Matthew McClintock wrote: > >>>> I’m seeing this too, same commit if you want another person to test/reproduce. > >>> > >>> If you do a pull today, does that fix your problem? > >> > >> Hmm, no. Which commit am I looking for? I’m on a56f489502e28caac56c8a0735549740f0ae0711 > > > > Commit 84787c572d402644dca4874aba73324d9f8e3948 is working for me. I have a fixup in lib/iov_iter.c with a dump_stack() call if the fixup was needed. That dump is not triggered. I do not seem to have a56f489502e yet. > > Still seeing the issue on top of tree and the above commit. Re-ran bisection just to be sure. Guys, the bug is real and definitely still there. char c; struct iovec v[2] = {{&c, 0}, {&c, 1}}; readv(0, v, 2); will trigger it just fine with stdin on e.g. tty. It needs fixing and I'll post a fix as soon as it gets through the local testing. In the meanwhile, I would like to know what in userland is doing that kind of call - kernel certainly shouldn't end up in an infinite loop on that, but it's bloody odd and I wonder what's going on in userland code to result in that call. Again, I understand what's going on kernel-side; the only tricky part is how to fix it without bringing the nasal daemons back. I think I have a solution and I'm going to post it tonight if it survives the local beating. In any case, the testcase above deserves being added to LTP - it's a real regression.
Powered by blists - more mailing lists