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 C4A66C001B0 for ; Thu, 10 Aug 2023 15:00:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 51ED36B0078; Thu, 10 Aug 2023 11:00:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4A84A6B007B; Thu, 10 Aug 2023 11:00:19 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3215A6B007D; Thu, 10 Aug 2023 11:00:19 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 1E77F6B0078 for ; Thu, 10 Aug 2023 11:00:19 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id D1C5C12105A for ; Thu, 10 Aug 2023 15:00:18 +0000 (UTC) X-FDA: 81108505716.19.97E36D3 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf17.hostedemail.com (Postfix) with ESMTP id 72F2540039 for ; Thu, 10 Aug 2023 15:00:09 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=none; spf=pass (imf17.hostedemail.com: domain of robin.murphy@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=robin.murphy@arm.com; dmarc=pass (policy=none) header.from=arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1691679613; 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; bh=/SZ7u6+VIweEQCEfZhMCuAMPG3Ijow5ISKkhK2TvxqM=; b=clM+3Mj4WKBQ2TRZgSS6XIT7PyoTP+SjmG4gK5H7GL4h0gBd/X8i+AwoHVMZxpVlo4B7du wkmf7ooBgIzqkxiVkEqKUB626MCpFebb1aJKDJQfKylNinnVbJxICVNpYYiTuqVLTT4Nhj 2VjHTqrp9yG9ZyX2zxEf8kb5SUTAbTc= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1691679613; a=rsa-sha256; cv=none; b=zKBCfTOcrzZO1DZuOo1kKK4nazuJKatoyIvTDTmbnafye62DfLr7a03eYRwrnYgIglnHhg ZWTHMbiq3ywpqb4kKbgcFg1OGC+C8TgmLNS9FI6Z9rEU3d5vRzG7RBw56I+BZ3+RHA7iUn cMaF/dR8TCTIJeCzV991yTE7UybU5qI= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=none; spf=pass (imf17.hostedemail.com: domain of robin.murphy@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=robin.murphy@arm.com; dmarc=pass (policy=none) header.from=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id E5AA3113E; Thu, 10 Aug 2023 08:00:50 -0700 (PDT) Received: from [10.1.196.40] (e121345-lin.cambridge.arm.com [10.1.196.40]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id DE3613F64C; Thu, 10 Aug 2023 08:00:06 -0700 (PDT) Message-ID: <10095b14-c005-c791-7e3e-d6561dac4dec@arm.com> Date: Thu, 10 Aug 2023 16:00:00 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux aarch64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: [BUG kernel-5.15] aarch64: __pi_strncmp() out-of-bound error Content-Language: en-GB To: Will Deacon Cc: Mark Rutland , =?UTF-8?B?Sm9obiBIc3UgKOioseawuOe/sCk=?= , "catalin.marinas@arm.com" , "linux-kernel@vger.kernel.org" , "linux-mediatek@lists.infradead.org" , =?UTF-8?B?WGlhb2JpbmcgU2hpICjlj7LlsI/lhbUp?= , =?UTF-8?B?Q2h1bmh1aSBMaSAo5p2O5pil6L6JKQ==?= , "linux-mm@kvack.org" , =?UTF-8?B?S3Vhbi1ZaW5nIExlZSAo5p2O5Yag56mOKQ==?= , =?UTF-8?B?Q2FzcGVyIExpICjmnY7kuK3mpq4p?= , "linux-arm-kernel@lists.infradead.org" References: <729b1505-c466-8a71-6079-4b0d9f81731d@arm.com> <20230810143118.GA5795@willie-the-truck> From: Robin Murphy In-Reply-To: <20230810143118.GA5795@willie-the-truck> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Stat-Signature: k73ow59s338jfimhhm3455sr8tnokwje X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 72F2540039 X-Rspam-User: X-HE-Tag: 1691679609-813037 X-HE-Meta: U2FsdGVkX1+K/RqpKNbHObDLnaLze0J07tUDvxKZISwlblOG+qYVwHDNXvdmynTlLOL1QBeQw5gcJqzOk230zdRWAYMPf160vTbgY6CCitTon6S7ZNCrXErDvJgKvyyHldB/pDEK+8JGPSxYpylSCxljn6DkacYhvyIMGsnYmPZ6tQ8uLHB2mnLpDOZ3+XzvjF7RCTuxxTz665m7jsmG6WXR01tkEGhq1wtnVjpUSMP3X3Gxpwfp4/eXnkzM4kEcjsI9O4XV0Bxxg3rvhJAoM5a3vX6G9RqOne1OtSPlNSeAQ0xLKBUT71jiW6ev5gQEO3QTc6JjSAuXCEW4xZ+vKw6OXSok28Ry0JBfZbShJ14XurXdxcz8RMecB2ote4RZvPLifI3iW/rJ/MadUBuj5CXsp4VT7k5nDvIkBnEk7W699GaNA7+0Zu/DHBkJoEWNmmD4FUHaUwoahQ2z6qEIE+45n++KaMtJM4+mw33OV2cLdQK0Wadh2QpeidK7XVxSIQGUWZtGUf5n7Dsw1XYiw0/e2cTILoYbirFt35xqqATF124YUuYXfkRtiBsZribhTOTjfk0A1zWEsqJRpTeZS6S1dk8ClkvLHt86b5klghKXcTzNjzKpFg2Z0KjU+4407JzAaQgY0BpNvf6H+Kn6gtMK025T82x04WC9lTV+ThjN5d49f0jeGzoikMKoz7A3kJWG3c2WGfPD4YEIMbfLD3NzdCkKcoySb0UmcyKauGTQ8ij7YLTZZEPKzxhTs/2Z/KNwWVnzOfRpr17FvYMYMWOINY6SA1c/P+7oOqXQ3Bp05siZoX8p7ur/cC972PhEXERf4AYK9HYO1s2pIQ8uLiaD838PKFztwFnYTXU88jQhI9DkVTjrRBbEq9KOKsW0P0Us6YyUqLutMcdYWTCz4QxYf7Owb1vqM5dCWx4FO6GojATgTC+WxXsrhPNZ6Y4WaFcjOWjX5P2n3fvtYiE t+AJmzXo vyA2bt1elsrcMuPsMY6zX9V3lbTStqvSGz1RPX7XKxzNTIf2wmSu4P7x/TvvSwlaJp9lZTYgrGaF889QhTHrZwpR6EYO9x7gzifOP6SPL+X7rBoT7eMlbEjzaeV+7rCMWrc4YByxL/rVNMb4Ov/I8pyw1zuRvTIr9rtX51O4J8LsMsx3uWfgdYhsJqykpEPFVlD0O X-Bogosity: Ham, tests=bogofilter, spamicity=0.000006, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 10/08/2023 3:31 pm, Will Deacon wrote: > 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. Bleh, poor choice of words... obviously there is a bug overall, it just might arguably be in the caller's expectations rather than the strncmp() implementation itself. However I would concur that there's no way we're going over all ~3000 strncmp() callsites with the "well, actually" comb just for this. It was more to say I don't think it's worth digging much deeper into exactly why, and I agree the pragmatic thing to do is either rip it out or backport the newer MTE-safe implementation which should be more robust. Cheers, Robin.