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: <87oaqvd6ni.fsf@x220.int.ebiederm.org>
Date:	Mon, 22 Dec 2014 09:51:45 -0600
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Andrey Ryabinin <ryabinin.a.a@...il.com>
Cc:	Sasha Levin <sasha.levin@...cle.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

Andrey Ryabinin <ryabinin.a.a@...il.com> writes:

> 2014-12-22 17:37 GMT+03:00 Sasha Levin <sasha.levin@...cle.com>:
>> Hi all,
>>
>> While fuzzing with trinity inside a KVM tools guest running the latest -next
>> kernel, I've stumbled on the following spew:
>>
>> [ 2015.960381] general protection fault: 0000 [#1] PREEMPT SMP KASAN
>
> Actually this is NULL-ptr dereference. Since you are using kasan with
> inline instrumentation
> NULL-ptr deref transforms into GPF.
>
>
>> [ 2015.970534] RAX: 0000000000000000 RBX: ffff88000003a960 RCX: 0000000000000073
>> [ 2015.970534] RDX: 1ffff10101c8f3c4 RSI: 0000000000000000 RDI: ffff88080e479e20
>> [ 2015.970534] RBP: ffff88080e477a28 R08: 0000000000000066 R09: 0000000000000073
>> [ 2015.970534] R10: ffffda0017d55630 R11: dfffe90000000000 R12: ffff88005fc644b8
>> [ 2015.970534] R13: dfffe90000000000 R14: ffffffff92464884 R15: 0000000000000000
>
> [...]
>
>> All code
>> ========
>>    0:   e8 03 42 80 3c          callq  0x3c804208
>>    5:   28 00                   sub    %al,(%rax)
>>    7:   0f 85 ff 01 00 00       jne    0x20c
>>    d:   4c 8b 7b 18             mov    0x18(%rbx),%r15
>>   11:   4d 85 ff                test   %r15,%r15
>>   14:   0f 84 de 01 00 00       je     0x1f8
>>   1a:   41 f6 c7 07             test   $0x7,%r15b
>>   1e:   0f 85 d4 01 00 00       jne    0x1f8
>>   24:   4c 89 f8                mov    %r15,%rax
>>   27:   48 c1 e8 03             shr    $0x3,%rax
>>   2b:*  42 80 3c 28 00          cmpb   $0x0,(%rax,%r13,1)               <-- trapping instruction
>
> Three commands above are result of KASAN's instrumentation.
> They check shadow for address in %r15:
>      if (*((%r15 >> 3) + kasan_shadow_offset)
>
>
>>   30:   0f 85 b5 01 00 00       jne    0x1eb
>>   36:   4d 8b 37                mov    (%r15),%r14
>
> And here is memory access, that KASAN checking.

Then frankly I suspect this is a KASAN bug.

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.

What other horrible things does KASAN do to the machine code?

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/