From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id A0B8DC41513 for ; Thu, 10 Aug 2023 14:31:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 336976B0071; Thu, 10 Aug 2023 10:31:28 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2E5806B0072; Thu, 10 Aug 2023 10:31:28 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1AD736B0075; Thu, 10 Aug 2023 10:31:28 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 0B9346B0071 for ; Thu, 10 Aug 2023 10:31:28 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id B55B012105A for ; Thu, 10 Aug 2023 14:31:27 +0000 (UTC) X-FDA: 81108433014.05.9C76C9B Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf27.hostedemail.com (Postfix) with ESMTP id CD19D4002B for ; Thu, 10 Aug 2023 14:31:25 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=Vo6x9fNk; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf27.hostedemail.com: domain of will@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=will@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1691677885; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=6pUA2GI5xCBNHG3O6xla7FzoUqibB38scILl8j/ZZ1E=; b=qcrNZgl2Kl0lVnUIBsdEuhWljd2JsaPX6v/rYpVbphf4gCzn+Al+NdPdPtW47B0TtpodC+ NWdf6W9w8qBAsJfVMsXG4YukExgNT/GUMT0mmcntkTv8rbGOex95N5Pi13UBs28+Hfyx8y ZmEjNYFEp2wM1t14blaSgiRwJdUbGy4= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=Vo6x9fNk; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf27.hostedemail.com: domain of will@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=will@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1691677885; a=rsa-sha256; cv=none; b=68ksCgVE+ubmtyQvoFWYQlmg7wQiRut8u/qmWk6R0sMj79zOUeZxXv5p2Zfs0uOG38XebN O624tlNg2CUMOnxTXutwHCBlc+2fIcjQZC7NGkYZOU7fAePVXaDCzwCCNsJpZ0mDUiE5s0 d4fyyyFYRKQN3PyTbdOZyRCX2AAT+cY= Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id C7C336198E; Thu, 10 Aug 2023 14:31:24 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 07BA6C433C8; Thu, 10 Aug 2023 14:31:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1691677884; bh=NDbeK3r+TzPIvE9JhJqOwEVEa7SuAW/RckgxxCkFemE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Vo6x9fNk+oY5praPuNnE6DfQGL01RwksDX1vcRMC0kXjQ83bFIqa2H6tnVABeBUXn rFsv0A1fcODcUdr55E0ytNUsmCVIw7O7SWKPYTACCbpPssFoOcd1VBqBDmWDGlMEC3 JqkFBQoNsFlCz8pVHFmpUiRB7IHDKVJdP8bOVJyqIrmQA8OCO3yGQjsnSdVyER62Cu 6eHa1lunqsnZTFncapFPWx/1q+Sq/c0tBpjku/c+//+QqydrrQQcEBR/W2N7CNEjRS qK4aWm7DwP0aXRkInCOa0SbrHR1ZYbZXd20I362p94j2aG/FAcRA8+uS5hq0nEv5Uz 57ct/JH8yhz+g== Date: Thu, 10 Aug 2023 15:31:18 +0100 From: Will Deacon To: Robin Murphy Cc: Mark Rutland , John Hsu =?utf-8?B?KOioseawuOe/sCk=?= , "catalin.marinas@arm.com" , "linux-kernel@vger.kernel.org" , "linux-mediatek@lists.infradead.org" , Xiaobing Shi =?utf-8?B?KOWPsuWwj+WFtSk=?= , Chunhui Li =?utf-8?B?KOadjuaYpei+iSk=?= , "linux-mm@kvack.org" , Kuan-Ying Lee =?utf-8?B?KOadjuWGoOepjik=?= , Casper Li =?utf-8?B?KOadjuS4reamrik=?= , "linux-arm-kernel@lists.infradead.org" Subject: Re: [BUG kernel-5.15] aarch64: __pi_strncmp() out-of-bound error Message-ID: <20230810143118.GA5795@willie-the-truck> References: <729b1505-c466-8a71-6079-4b0d9f81731d@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <729b1505-c466-8a71-6079-4b0d9f81731d@arm.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-Rspamd-Queue-Id: CD19D4002B X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: 5k39pubbt7gxta868aubh7njk4grda1w X-HE-Tag: 1691677885-513308 X-HE-Meta: U2FsdGVkX19b+2LI9C9Lb1hU9IE53iEBQ3jUAvEm5uFXb3Zyo3g9mAJfXvQ+YiTQTStgahhV643M595xGzECaCTeP2phBHoXNjMIOqYHAegm4S2uP2qXLHtLBF9pfquzMjdO3jft252wzhS9Y0N/NTIrq6jOjiAWKXKjXFkvsgOTGNLjrpYp04/Eg792x+e8sHmDThZcpK+iJAPmPxrK8VSJ8mAswkr//JtMManWTHH8a2yJH5yrWeXTAS6PxDdDyEx0Hs0+/oKZDFudFzGti25Izfam2LLdlAk6H/XHsfazJ0QeW20u0ZTsjdz5+HUjQIjcJYamMJvIoGQHIKy7IfZ1VCfJJ6T7iFXFYfNflavGA4MFBaogV1LBt1b4N6kXuhpjw8PF0Hj7Mzx6OJn2P0AQwTsuTKhZMMAZCGBHab7NHieYVF/fQTys1WcKZVcUq41bnWrGWDJSY3SuKWhmk3bsAdMMr+fHiZxm78IJu0+K0ttAVDBuaiGongnrj8p8PbJp5EuyP69EcLRn8EDFnEtplgluPF0v6gQZfvaqn9YjEKQluBtYTBsusF53b7eK0fFStfCihD5G8v/PfQj7BEYwFrBKYEn3e/Agx/qwEO9YcZP2LcFMqLmMeoG/vYf3Lcx8Nh32IykeH9wKeIotPLqNSJXhkK3Rnt+P3gdtPaFYo6s751wNgQMm+p+nWeFVGkd/7Udb6dR2ee0CpASwTz/KU85AqEZZNv60nzPRdKnTPsSmA/bqVK/wRyga1Zt44OAc8x3S/JKgcqYEQ4F3Hvda/v9wsYAXv2y9X9qMS/k5AQiDAbl2wsE59oPtfi/ulYF7lvRXiDI1uqeInqfW0P7KJPp3iKyaJXlHICZWYJZojqWT6jwGqjwOhcHgvbGtNm1h+oXeawYJoCaZyBe4BnO5wPTydWuNV5YLS+EZAkgngm23PCa7BFaSk18i4+v3PjVKyH9KYlr5wribF5l qz7io+yE LUn6in8c9P+9YAK3/6h4w2zzZfL/4EazQdh0k63GiaUihtj2OwnqP+lmr9MHtZcdel9YSuxU9UaAnOQ3D3W3x9R3ScgQNfagrLscraPlzp+3OgM7rQin4s4c/P+mdXh0KnjCKsFbvKlAB2fJNXrYWDzR4QWgiKxur4zfF48H49osHyyU5PT9V9TJKSJnH34F9nN7tDscLb4ukZ0W1jCDg/S2ptnIbnrIGGgb0PA488W6PJNqNyWTKJBSmH1IE/samLbMjS60QCmq8kNp6kVTaMv6WqELsPeDy0YgPiSWIphdUDRH5xD9qzWsJCxIil/uqP7o+48UfRIwkVubo+S8ZLCq3b5C60zpom9qolixdLptPculouZBde/EeIg== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, Aug 10, 2023 at 01:23:28PM +0100, Robin Murphy wrote: > On 2023-08-07 16:32, Mark Rutland wrote: > > On Mon, Aug 07, 2023 at 12:31:45PM +0000, John Hsu (許永翰) wrote: > > > [ 7445.269347][ T382] ueventd: Hardware name: MT6886(ENG) (DT) > > > [ 7445.269354][ T382] ueventd: Call trace: > > > [ 7445.269359][ T382] ueventd: dump_backtrace+0x0/0x2a8 > > > [ 7445.269374][ T382] ueventd: dump_stack_lvl+0x74/0xa4 > > > [ 7445.269384][ T382] ueventd: dump_stack+0x14/0x1c > > > [ 7445.269391][ T382] ueventd: mrdump_common_die+0x32c/0x5ac [mrdump] > > > [ 7445.269470][ T382] ueventd: ipanic_die+0x1c/0x28 [mrdump] > > > [ 7445.269539][ T382] ueventd: __die+0xbc/0x308 > > > [ 7445.269548][ T382] ueventd: die+0xd8/0x500 > > > [ 7445.269556][ T382] ueventd: die_kernel_fault+0x94/0xa8 > > > [ 7445.269565][ T382] ueventd: __do_kernel_fault+0x1d8/0x214 > > > [ 7445.269571][ T382] ueventd: do_bad_area+0x40/0x174 > > > [ 7445.269579][ T382] ueventd: do_translation_fault+0x48/0x54 > > > [ 7445.269585][ T382] ueventd: do_mem_abort+0x3c/0x100 > > > [ 7445.269592][ T382] ueventd: el1_abort+0x38/0x54 > > > [ 7445.269602][ T382] ueventd: el1h_64_sync_handler+0x54/0x88 > > > [ 7445.269610][ T382] ueventd: el1h_64_sync+0x78/0x7c > > > [ 7445.269618][ T382] ueventd: __pi_strncmp+0x1a0/0x1c4 > > > [ 7445.269626][ T382] ueventd: selinux_genfs_get_sid+0x114/0x220 > > > [ 7445.269636][ T382] ueventd: inode_doinit_with_dentry+0x3d0/0x598 > > > [ 7445.269644][ T382] ueventd: selinux_d_instantiate+0x1c/0x24 > > > [ 7445.269652][ T382] ueventd: d_splice_alias+0x5c/0x280 > > > [ 7445.269662][ T382] ueventd: kernfs_iop_lookup+0xec/0x21c > > > [ 7445.269674][ T382] ueventd: __lookup_slow+0xc4/0x150 > > > [ 7445.269684][ T382] ueventd: lookup_slow+0x40/0xf0 > > > [ 7445.269690][ T382] ueventd: walk_component+0x144/0x160 > > > [ 7445.269696][ T382] ueventd: link_path_walk+0x25c/0x344 > > > [ 7445.269703][ T382] ueventd: path_lookupat+0x64/0x120 > > > [ 7445.269710][ T382] ueventd: filename_lookup+0xc4/0x1b0 > > > [ 7445.269718][ T382] ueventd: user_path_at_empty+0x48/0xb4 > > > [ 7445.269725][ T382] ueventd: do_faccessat+0xa8/0x1f0 > > > [ 7445.269732][ T382] ueventd: __arm64_sys_faccessat+0x20/0x28 > > > [ 7445.269738][ T382] ueventd: invoke_syscall+0x3c/0xf0 > > > [ 7445.269746][ T382] ueventd: el0_svc_common+0x84/0xe8 > > > [ 7445.269753][ T382] ueventd: do_el0_svc+0x20/0x84 > > > [ 7445.269759][ T382] ueventd: el0_svc+0x1c/0x48 > > > [ 7445.269766][ T382] ueventd: el0t_64_sync_handler+0x7c/0xd8 > > > [ 7445.269773][ T382] ueventd: el0t_64_sync+0x15c/0x160 > > > We found that we hit this issue when we compare these two strings. > > > ________________address|_0__1__2__3__4__5__6__7__8__9__A__B__C__D__E__F > > > __ 0123456789ABCDEF > > > NSD:FFFFFF80089EDA00|>2F 64 65 76 69 63 65 73 2F 76 69 72 74 75 61 > > > 6C /devices/virtual > > > NSD:FFFFFF80089EDA10| 2F 62 6C 6F 63 6B 2F 00 E0 03 01 AA E1 03 02 > > > AA /block/......... > > > ________________address|_0__1__2__3__4__5__6__7__8__9__A__B__C__D__E__F > > > __ 0123456789ABCDEF > > > NSD:FFFFFF803FD3EFE0| 00 00 00 00 00 00 00 00 00 00 2F 64 65 76 69 > > > 63 ........../devic > > > NSD:FFFFFF803FD3EFF0| 65 73>2F 76 69 72 74 75 61 6C 2F 6D 69 73 63 > > > 00 es/virtual/misc. > > > NSD:FFFFFF803FD3F000| ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? > > > ?? > > > NSD:FFFFFF803FD3F0E0| ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? > > > ?? > > > > > > We observe the second string is put at the tail of the first page and > > > the next page is unreadable. > > > Thus, we made a simple test as below and it can reproduce this issue. > > I'm not sure there's strictly a bug here. The C standard says: > > "The strncmp function compares not more than n characters (characters that > follow a null character are not compared) ..." > > so although any characters between the first NULL and n must not be > considered for the result of the comparison, there doesn't seem to be any > explicit promise anywhere that they can't be *accessed*. AFAICT what happens > here is in the request to compare at most 23 characters, it ends up in the > do_misaligned case, loop_misaligned runs twice and finds no differences or > NULLs in characters 0-7 and 8-15, so then done_loop loads characters 15-23 > to compare the last 7, and is tripped up by 22-23 not actually existing in > src2. Possibly the original intent was that this case should have ended up > in page_end_loop, and the condition for that was slightly off, but I'm not > sure, and this code is obsolete now anyway. The long backtrace above worries me, as it suggests that you can trigger this from userspace. In that case I think it's a bug regardless of what the C standard says. Perhaps we should just fallback to the generic strncmp() implementation in the stable kernel? I couldn't spot any other architectures doing anything particularly clever, and x86_64 looks like it doesn't select __HAVE_ARCH_STRNCMP at all. Will