linux-kernel - Re: fs: proc: gpf in find

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: <87sig7beqt.fsf@x220.int.ebiederm.org>
Date:	Mon, 22 Dec 2014 14:39:54 -0600
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Sasha Levin <sasha.levin@...cle.com>
Cc:	Andrey Ryabinin <ryabinin.a.a@...il.com>,
	LKML <linux-kernel@...r.kernel.org>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	Al Viro <viro@...iv.linux.org.uk>,
	"davej \@mail.xmission.com\>\> Dave Jones" <davej@...hat.com>
Subject: Re: fs: proc: gpf in find_entry

Sasha Levin <sasha.levin@...cle.com> writes:

> On 12/22/2014 12:52 PM, Andrey Ryabinin wrote:
>> 2014-12-22 18:51 GMT+03:00 Eric W. Biederman <ebiederm@...ssion.com>:
>>> These two instructions:
>>>>>   11:   4d 85 ff                test   %r15,%r15
>>>>>   14:   0f 84 de 01 00 00       je     0x1f8
>>>
>>> Should prevent a NULL %r15 value from ever reaching the trapping
>>> instruction.
>> 
>> If they were executed, then yes. But I think there was jump from somewhere
>> to the instructions below those two.
>
> There is indeed a jump direct to that point, which avoids the %r15
> check.

Where do you see that direct jump, that certainly has not been posted
in this thread?

There are certainly no such code paths I in the source code.  There is
only one NULL pointer check in find_entry and it is executed every time
the loop executes.

So at this point all I know is some set of tools has totally destroyed
the code and made what Sasha Levin's is testing so far from the source
code that this is a useless bug report.

I have no reason to even suspect this bug is actually in the upstream
kernel.

This appears to be a kind of testing that slows development and wastes
peoples time.  Can someone give me a patch that sets the TAINTED flag
when KASAN is loaded?

Eric

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/