linux-kernel - Re: [patch 1/2] x86/process: Add proper bound checks in 64bit get

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] [day] [month] [year] [list]
Message-ID: <CACT4Y+amnG4=QdDtgPJstc4C2mePgLg7KBeePpt1c1CGqqFvbQ@mail.gmail.com>
Date:	Sun, 4 Oct 2015 14:14:38 +0200
From:	Dmitry Vyukov <dvyukov@...gle.com>
To:	Andrey Ryabinin <ryabinin.a.a@...il.com>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	Sasha Levin <sasha.levin@...cle.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Andy Lutomirski <luto@...capital.net>,
	Andrey Konovalov <andreyknvl@...gle.com>,
	Kostya Serebryany <kcc@...gle.com>,
	Alexander Potapenko <glider@...gle.com>,
	kasan-dev <kasan-dev@...glegroups.com>,
	Borislav Petkov <bp@...en8.de>,
	Denys Vlasenko <dvlasenk@...hat.com>,
	Andi Kleen <ak@...ux.intel.com>,
	"x86@...nel.org" <x86@...nel.org>,
	Wolfram Gloger <wmglo@...t.med.uni-muenchen.de>
Subject: Re: [patch 1/2] x86/process: Add proper bound checks in 64bit get_wchan()

On Sat, Oct 3, 2015 at 1:31 PM, Andrey Ryabinin <ryabinin.a.a@...il.com> wrote:
> 2015-10-03 13:54 GMT+03:00 Thomas Gleixner <tglx@...utronix.de>:
>> On Fri, 2 Oct 2015, Sasha Levin wrote:
>>> I'm seeing a different issue with this patch:
>>>
>>> [ 5228.736320] BUG: KASAN: out-of-bounds in get_wchan+0xf9/0x1b0 at addr ffff88049d2b7c50
>>> [ 5228.737560] Read of size 8 by task killall/22177
>>> [ 5228.738304] page:ffffea001274adc0 count:0 mapcount:0 mapping:          (null) index:0x0
>>> [ 5228.739374] flags: 0x6fffff80000000()
>>> [ 5228.739862] page dumped because: kasan: bad access detected
>>> [ 5228.741764] CPU: 8 PID: 22177 Comm: killall Not tainted 4.3.0-rc3-next-20151002-sasha-00076-gde7fa56-dirty #2590
>>> [ 5228.743337]  ffff882c80967828 000000007a901a83 ffff882c80967790 ffffffffacd2c8c8
>>> [ 5228.744409]  ffff88049d2b7c50 ffff882c80967818 ffffffffab74befb ffff882c8bd00000
>>> [ 5228.745436]  0000000000000002 0000000000000282 ffff882c8bd00cf8 0000000000000001
>>> [ 5228.746446] Call Trace:
>>> [ 5228.746881] dump_stack (lib/dump_stack.c:52)
>>> [ 5228.747720] kasan_report_error (include/linux/kasan.h:28 mm/kasan/report.c:170 mm/kasan/report.c:237)
>>> [ 5228.748670] __asan_report_load8_noabort (mm/kasan/report.c:279)
>>> [ 5228.750563] get_wchan (arch/x86/kernel/process.c:561)
>>> [ 5228.751378] do_task_stat (fs/proc/array.c:458)
>>> [ 5228.755912] proc_tgid_stat (fs/proc/array.c:565)
>>> [ 5228.756770] proc_single_show (./arch/x86/include/asm/atomic.h:118 include/linux/sched.h:2012 fs/proc/base.c:789)
>>> [ 5228.759066] seq_read (fs/seq_file.c:238)
>>> [ 5228.762360] __vfs_read (fs/read_write.c:432)
>>> [ 5228.767957] vfs_read (fs/read_write.c:454)
>>> [ 5228.769368] SyS_read (fs/read_write.c:570 fs/read_write.c:562)
>>> [ 5228.778344] entry_SYSCALL_64_fastpath (arch/x86/entry/entry_64.S:186)
>>> [ 5228.779272] Memory state around the buggy address:
>>> [ 5228.779971]  ffff88049d2b7b00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>> [ 5228.780992]  ffff88049d2b7b80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>> [ 5228.782021] >ffff88049d2b7c00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>> [ 5228.783066]                                                     ^
>>> [ 5228.783936]  ffff88049d2b7c80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>> [ 5228.784994]  ffff88049d2b7d00: 00 00 00 00 00 f1 f1 f1 f1 00 f4 f4 f4 f3 f3 f3
>>>
>>>         fp = READ_ONCE(*(unsigned long *)sp);
>>>         do {
>>>                 if (fp < bottom || fp > top)
>>>                         return 0;
>>>                 ip = READ_ONCE(*(unsigned long *)(fp + sizeof(unsigned long)));
>>>                 if (!in_sched_functions(ip))
>>>                         return ip;
>>>                 fp = READ_ONCE(*(unsigned long *)fp); <=== Here
>>
>> Weird, we accessed
>>
>>      *(unsigned long *)(fp + sizeof(unsigned long))
>>
>> a few lines above, i.e. ffff88049d2b7c58
>>
>> But what's more weird is that the memory dump does not really look
>> like a stack at all.
>>
>> ffff88049d2b7c50 is stored on the stack:
>>
>>> [ 5228.744409]  ffff88049d2b7c50 ffff882c80967818 ffffffffab74befb ffff882c8bd00000
>>
>> But if it is not inside the stack bounds, how do we end up
>> dereferencing it. Confused....
>>
>
> I'm sure that we in stack bounds here.
> But we are not inside bounds of some stack variable
> and KASAN doesn't like it.

Agree.

> KASAN changes stack frame of each function, e.g.
>     void foo() {
>             int a;
>     }
>
> transformed to:
>     void foo() {
>             char redzone1[32];
>             int a;
>             char redzone2[28];
>             char redzone3[32];
>     }
>
> So any access to redzones will be reported.
>
> I could make a patch which will tell KASAN to ignore get_wchan(),
> but if there are any real bugs left in get_wchan() they will be ignored too.

Yes, we need KASAN to ignore it. False positives are not acceptable. I
wanted to mail a fix after the fix for the real bug. I am thinking
about kasan_disable_current/kasan_enable_current around the region
that does the stack accesses; the reports are rare enough, so it
should not have any significant performance effect. I don't mind if
you send the patch.
--
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/