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 B0AD0EE14B9 for ; Wed, 6 Sep 2023 18:07:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 34FA38E0015; Wed, 6 Sep 2023 14:07:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2D8DC8D0005; Wed, 6 Sep 2023 14:07:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1521A8E0015; Wed, 6 Sep 2023 14:07:23 -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 02FA48D0005 for ; Wed, 6 Sep 2023 14:07:23 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id BE8A7140E4A for ; Wed, 6 Sep 2023 18:07:22 +0000 (UTC) X-FDA: 81206954724.02.102DA4A Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf09.hostedemail.com (Postfix) with ESMTP id 0052C140003 for ; Wed, 6 Sep 2023 18:07:20 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=KfJ6SGey; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf09.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=1694023641; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=LKlxMwUUPTxt5CEqWkiIRwix0QCPHH/Qrv+2DhWCGLc=; b=AN9E30+Ck/n9JeTzbEz448nirOTvh17lyoCviPFglDD1oG4INaYAUtH6DupfpHo2nv8TPi tMkqXK1sTbRkkK16UlQQPVoScN5t9q4dnaBt6IsYA8mzTbFbA7/w+WEcFNcT4KSmkqK6hc JVq+3L8akk2BzUhhYl9VTXrf73HYCYg= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=KfJ6SGey; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf09.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=1694023641; a=rsa-sha256; cv=none; b=Ej7fR/58eKWWWuhn3l3Ta7dy9IwgH2zUSHWEu3xrx4QQ78r37enYtfOTsqhKS8wxrp/VYb HWAqMaVugifngRqeYifUmvDdT4u629zj8zInNPDvtEDKSGIP6YUJO5ReNc6zpEVXi2yYpt zDS4dVtFUytzv985xaaXSe9gwhSUoYM= 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 0ECCD60FEB; Wed, 6 Sep 2023 18:07:20 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4438FC433C7; Wed, 6 Sep 2023 18:07:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1694023639; bh=LK/9RFwAWACpDVkJmUMLa4ZQcl1iT5eciMmgvqDRP+s=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=KfJ6SGeyG/KrBP0dZuQ2sQn02bCkZJ+aM3V9f3+RZeEMWUjQHqk285OqMaVDaWaoi yqy6yyVu+LRLQmKbJ8g0LeMvVQWCFHWQsKfkrR5BWxUJSrPNvPf1TdVCFOoFZTkyzw dbvYxwRmTj15VMEidM58t1UQbkFrFx1OPft6GG6y9Phn68dO7pLyZGccuojTDjHOvI RvgbLnjk52ttRqS5AZjfBEDYoGBIedPuanlO8owmfxva7SgyMFNcvPuhkDjQbPZzrt WVC/QtBxOYPwXJCvHqpo2VQM5k2gQGfFrAseWzht+W5ZOaHYI8/98H0lNjApjNPOBY PW4FubQkVUrmw== Date: Wed, 6 Sep 2023 19:07:13 +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: <20230906180713.GA5021@willie-the-truck> References: <729b1505-c466-8a71-6079-4b0d9f81731d@arm.com> <20230810143118.GA5795@willie-the-truck> <10095b14-c005-c791-7e3e-d6561dac4dec@arm.com> <20230810160907.GA5951@willie-the-truck> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230810160907.GA5951@willie-the-truck> User-Agent: Mutt/1.10.1 (2018-07-13) X-Rspamd-Queue-Id: 0052C140003 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: dubhxhkqqjnc1ug5zofjmk9aetcisiuf X-HE-Tag: 1694023640-368656 X-HE-Meta: U2FsdGVkX19B2Mo6GfBZAyykCkvaUj5GfT/Uae6vCv1vslZqZhBrp/UP+n4RURp64SOl4UVQVzPnMd7+CaLBB/0JPQXD9/9xVWkOQwDl9mOar1QypXLnAKUc4eLUUMN67+ujN5xM+p7JqowoVxEzJ7xvgMokew7dRoKbqF6YWkBHacA/HolrtZuXcnw4RcybEPsW9ln/HTWVMXSKQaHXOZvcr58cYQmGjfpOq9mu75qJ5jakVjft4455bx9xsQdW9GByB1s0i4afVQwKSPGL8qzXxt4Qzd2c+pA7k1Qz8frXy19LcykCNwiQWryuZUbFMjSbIEIhfWAWaF/uHk77ncSDJ03Uy3xOmSAalUf+idSL2qHRaNVNWxOCCLA47ZEx125kUZdvnHw/hy5rhfuC3Re8M38dxvlTG5E8ctjFSxLDkE0f3wCuraz6eSqfWIK4u167t9aS5YWxFCtsNeK88wBh+S1RTBaHbR35br/vhDwgp85T/AQCXVakv4//dRaV5YqqlCnkZZLOYYAOXG0CSZQYKsxEhr13VNvMqIiF19zOuEOn+umhQ1wVMsH+IkLpbLg/PmgFXUGW+qJm9dSq13F8zaUFIpLZNpR7mce+ivkeNwLP6jtCgdfeBHk24hvd8CY2M6OzeTMJLP479ywz8CmjQ7zaorvYLXVz1zXV76DbhxwQNz6mRYaQWXMkJF2tT+3tQsvq7VmH6n2O5f2trxDWkrCGvf9vGL5/E6GIbKdnVNKqsptaZrUlTBvDH+eJWlTdEtQhhhF5Ld269l9UnHO18QP9miKE2sMJvUp2qtL3nuUhvQoTb6M7kY90caH28xIP7LL63QSbug1p9FSbzXa8MYbjOuhqFYjjR74eS7Bs7KX6RLLumk2XGhxRpD2FdzkufVQvtMd2RYb5XXEWPD+TIRlsMOSgAhUsfLC+qwOOK+kURaTX+eR30ybqvwn4qksd/nd1N6YylKMaCe2 B0zdaQtG 0DlnmgLH2jXOxHFDGYvLXta0t2+4CYKrCo55Lz7oacjCyoFgvvTGBSyhbIHqy/8Y8C/2V8e3ToHRDWrJyxNg0ABK9OiDMxKpl5BIa1a8CiEYm04akbdNdA3fj+0/wwkiYbkjN+FUZpAQP0jbvFxImgiq5OOI9w5yUFIVGMYmlszT+mMX1Z0P+cn4pFG61GMmy8MTlP3Nf7vDfzfLLi4+cRGA2IsKpUw7S/hBqh4paGigUm9uslj5PC4P+HD7GL0XGNRJ3Z2QdOerfM5i77hk+qvtrsDXhYu8aScVZZ7kyvT6oMJBtAf/gMe+Ez6Q6s2e7LyKiwaCUeSmPF5H2noNIxzVeTrynf/RIQNIIK5HRZsPg9lMIVh64B3nNIesBHY416f1dBQ5osouJ+P8LdWkXOymGnIMOWWbfjp/fmiaP4EB3rSSxlwapJacpJA== X-Bogosity: Ham, tests=bogofilter, spamicity=0.001567, 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 05:09:07PM +0100, Will Deacon wrote: > On Thu, Aug 10, 2023 at 04:00:00PM +0100, Robin Murphy wrote: > > On 10/08/2023 3:31 pm, Will Deacon wrote: > > > On Thu, Aug 10, 2023 at 01:23:28PM +0100, Robin Murphy wrote: > > > > 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. > > Heh, then we agree. I was worried you'd gone mad :) In the end I cherry-picked the newer implementation rather than fall back to the generic implementation: https://lore.kernel.org/r/20230906180336.4973-1-will@kernel.org Will