From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrey Ryabinin Subject: Re: [PATCH v4] x86/suspend: fix false positive KASAN warning on suspend/resume Date: Fri, 2 Dec 2016 23:55:55 +0300 Message-ID: <9cc8748f-9b52-4267-8237-b44084a48de4@virtuozzo.com> References: <20161201173438.bfe5eq23i6ezfxsq@treble> <20161201175611.gf63mwzomt4wrlxy@treble> <20161201203154.mwt5x736g7z6jh3o@treble> <5144d695-7ac4-f992-5239-91c772b0c121@virtuozzo.com> <20161202140147.gvj452hmlbxnstrg@treble> <20161202144240.3tect4hx4cks44iu@treble> <20161202150819.2h25oyoj7qsvrw77@treble> <20161202174221.sfcvvddbvl5uz4f4@treble> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Return-path: Received: from mail-db5eur01on0099.outbound.protection.outlook.com ([104.47.2.99]:47697 "EHLO EUR01-DB5-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751226AbcLCHlb (ORCPT ); Sat, 3 Dec 2016 02:41:31 -0500 In-Reply-To: <20161202174221.sfcvvddbvl5uz4f4@treble> Sender: linux-pm-owner@vger.kernel.org List-Id: linux-pm@vger.kernel.org To: Josh Poimboeuf Cc: Dmitry Vyukov , "Rafael J. Wysocki" , Len Brown , Pavel Machek , linux-pm@vger.kernel.org, LKML , Peter Zijlstra , Ingo Molnar , Andy Lutomirski , Scott Bauer , "x86@kernel.org" , Alexander Potapenko , kasan-dev On 12/02/2016 08:42 PM, Josh Poimboeuf wrote: > Resuming from a suspend operation is showing a KASAN false positive > warning: > > BUG: KASAN: stack-out-of-bounds in unwind_get_return_address+0x11d/0x130 at addr ffff8803867d7878 > Read of size 8 by task pm-suspend/7774 > page:ffffea000e19f5c0 count:0 mapcount:0 mapping: (null) index:0x0 > flags: 0x2ffff0000000000() > page dumped because: kasan: bad access detected > CPU: 0 PID: 7774 Comm: pm-suspend Tainted: G B 4.9.0-rc7+ #8 > Hardware name: Gigabyte Technology Co., Ltd. Z170X-UD5/Z170X-UD5-CF, BIOS F5 03/07/2016 > Call Trace: > dump_stack+0x63/0x82 > kasan_report_error+0x4b4/0x4e0 > ? acpi_hw_read_port+0xd0/0x1ea > ? kfree_const+0x22/0x30 > ? acpi_hw_validate_io_request+0x1a6/0x1a6 > __asan_report_load8_noabort+0x61/0x70 > ? unwind_get_return_address+0x11d/0x130 > unwind_get_return_address+0x11d/0x130 > ? unwind_next_frame+0x97/0xf0 > __save_stack_trace+0x92/0x100 > save_stack_trace+0x1b/0x20 > save_stack+0x46/0xd0 > ? save_stack_trace+0x1b/0x20 > ? save_stack+0x46/0xd0 > ? kasan_kmalloc+0xad/0xe0 > ? kasan_slab_alloc+0x12/0x20 > ? acpi_hw_read+0x2b6/0x3aa > ? acpi_hw_validate_register+0x20b/0x20b > ? acpi_hw_write_port+0x72/0xc7 > ? acpi_hw_write+0x11f/0x15f > ? acpi_hw_read_multiple+0x19f/0x19f > ? memcpy+0x45/0x50 > ? acpi_hw_write_port+0x72/0xc7 > ? acpi_hw_write+0x11f/0x15f > ? acpi_hw_read_multiple+0x19f/0x19f > ? kasan_unpoison_shadow+0x36/0x50 > kasan_kmalloc+0xad/0xe0 > kasan_slab_alloc+0x12/0x20 > kmem_cache_alloc_trace+0xbc/0x1e0 > ? acpi_get_sleep_type_data+0x9a/0x578 > acpi_get_sleep_type_data+0x9a/0x578 > acpi_hw_legacy_wake_prep+0x88/0x22c > ? acpi_hw_legacy_sleep+0x3c7/0x3c7 > ? acpi_write_bit_register+0x28d/0x2d3 > ? acpi_read_bit_register+0x19b/0x19b > acpi_hw_sleep_dispatch+0xb5/0xba > acpi_leave_sleep_state_prep+0x17/0x19 > acpi_suspend_enter+0x154/0x1e0 > ? trace_suspend_resume+0xe8/0xe8 > suspend_devices_and_enter+0xb09/0xdb0 > ? printk+0xa8/0xd8 > ? arch_suspend_enable_irqs+0x20/0x20 > ? try_to_freeze_tasks+0x295/0x600 > pm_suspend+0x6c9/0x780 > ? finish_wait+0x1f0/0x1f0 > ? suspend_devices_and_enter+0xdb0/0xdb0 > state_store+0xa2/0x120 > ? kobj_attr_show+0x60/0x60 > kobj_attr_store+0x36/0x70 > sysfs_kf_write+0x131/0x200 > kernfs_fop_write+0x295/0x3f0 > __vfs_write+0xef/0x760 > ? handle_mm_fault+0x1346/0x35e0 > ? do_iter_readv_writev+0x660/0x660 > ? __pmd_alloc+0x310/0x310 > ? do_lock_file_wait+0x1e0/0x1e0 > ? apparmor_file_permission+0x18/0x20 > ? security_file_permission+0x73/0x1c0 > ? rw_verify_area+0xbd/0x2b0 > vfs_write+0x149/0x4a0 > SyS_write+0xd9/0x1c0 > ? SyS_read+0x1c0/0x1c0 > entry_SYSCALL_64_fastpath+0x1e/0xad > Memory state around the buggy address: > ffff8803867d7700: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > ffff8803867d7780: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > >ffff8803867d7800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f4 > ^ > ffff8803867d7880: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 > ffff8803867d7900: 00 00 00 f1 f1 f1 f1 04 f4 f4 f4 f3 f3 f3 f3 00 > > KASAN instrumentation poisons the stack when entering a function and > unpoisons it when exiting the function. However, in the suspend path, > some functions never return, so their stack never gets unpoisoned, > resulting in stale KASAN shadow data which can cause later false > positive warnings like the one above. > > Reported-by: Scott Bauer > Signed-off-by: Josh Poimboeuf Acked-by: Andrey Ryabinin