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]

Date:	Mon, 22 Dec 2014 21:52:31 +0400
From:	Andrey Ryabinin <ryabinin.a.a@...il.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.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

2014-12-22 18:51 GMT+03:00 Eric W. Biederman <ebiederm@...ssion.com>:
> 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.
>

Sure it is possible, but I don't see any evidence of kasan bug here.

> 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.

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

kasan insert something like following before any memory access:

s8 *shadow_addr = (add >> 3) + shadow_offset;

if (unlikely(*shadow_addr))
     if (unlikely(addr & 7 >= *shadow_addr))
           report_bug(addr);


I suspect that Sasha is using kasan along with ubsan.
In that case generated code much more horrid.
--
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/