linux-kernel - Re: Regression in 4.6.0-git - bisected to commit dd254f5a382c

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]

Message-ID: <5745B67B.6040901@lwfinger.net>
Date:	Wed, 25 May 2016 09:28:11 -0500
From:	Larry Finger <Larry.Finger@...inger.net>
To:	Al Viro <viro@...IV.linux.org.uk>,
	Matthew McClintock <mmcclint@...eaurora.org>
Cc:	LKML <linux-kernel@...r.kernel.org>
Subject: Re: Regression in 4.6.0-git - bisected to commit dd254f5a382c

On 05/25/2016 01:24 AM, Al Viro wrote:
> On Wed, May 25, 2016 at 12:41:33AM +0100, Al Viro wrote:
>> 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.
>
> FWIW, the reproducer is
> #include <sys/uio.>
> main()
> {
> 	char c;
> 	struct iovec v[2] = {{&c,0},{&c,1}};
> 	readv(0, v, 2);
> }
> ran with stdin from tty.  Fix for that is simply
>
> diff --git a/lib/iov_iter.c b/lib/iov_iter.c
> index 28cb431..0cd5227 100644
> --- a/lib/iov_iter.c
> +++ b/lib/iov_iter.c
> @@ -101,7 +101,7 @@
>   #define iterate_and_advance(i, n, v, I, B, K) {			\
>   	if (unlikely(i->count < n))				\
>   		n = i->count;					\
> -	if (n) {						\
> +	if (i->count) {						\
>   		size_t skip = i->iov_offset;			\
>   		if (unlikely(i->type & ITER_BVEC)) {		\
>   			const struct bio_vec *bvec;		\
>
> Could you see if your reproducer is fixed by that?

Yes, that change fixes my reproducer. If this is the final fix, you may add a 
Tested-by: to the commit.

Larry

>