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 E3DD5D6D250 for ; Thu, 28 Nov 2024 00:58:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 554706B0083; Wed, 27 Nov 2024 19:58:53 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 504796B0085; Wed, 27 Nov 2024 19:58:53 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3F2986B0088; Wed, 27 Nov 2024 19:58:53 -0500 (EST) 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 212D66B0083 for ; Wed, 27 Nov 2024 19:58:53 -0500 (EST) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 3D4851A1177 for ; Thu, 28 Nov 2024 00:58:52 +0000 (UTC) X-FDA: 82833693894.23.300697D Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf05.hostedemail.com (Postfix) with ESMTP id A7F23100003 for ; Thu, 28 Nov 2024 00:58:38 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=jajX3pYp; spf=pass (imf05.hostedemail.com: domain of akpm@linux-foundation.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1732755523; 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=2QQvh6Fne0/dNE3sY7vQVCS96qM60tW5T1AI0etJVHM=; b=5rAbUecd2imM504A83okJW8HqdUYJlpzeghbt3urGZ5158HijRy23JHJlz46wQGQ23Eeig OR0cyGXBjaKiGFZBJoKd3DY40bSwHAGXUNGOjcD/p9t+uSftvqAlKW/e8HZCsbDGaqxAoC QJxbDvK82hJ/ZoEUraWraYEqVmMySoY= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=jajX3pYp; spf=pass (imf05.hostedemail.com: domain of akpm@linux-foundation.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1732755523; a=rsa-sha256; cv=none; b=qN4v7PbGCwB446yEI2DqTpLjNg2mGDhynhbwVKZyUsH9iiHAIzdTKxVFVQpFu3f1JNA/VE 1c5MXNzOQyEUOEb8Ernv8uZxEKx/lUnUQ1CCYtkXhApZL0e3P7vBicm9EU47ljpPsTKs89 HvtuWAp4skF9KL+Krhfs1WVfVj843yo= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 0AE57A43A48; Thu, 28 Nov 2024 00:56:57 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 38D15C4CECC; Thu, 28 Nov 2024 00:58:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1732755529; bh=5blE1A9Kn8XUlBJJA6u9dHT6buJUrLbL9a6/uglDLck=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=jajX3pYpHhvhgkUyS7vzFqML3k+ESkZV3Q8FbcrvyGGSSKQPGNlz49SwkcslHtxXH YTg5kW24bgXFCSN8WLP29fCWimuhQJCvJCZzBKbqpP+PamiJN5ZKRagXpiDudrAvw7 sXJsqRytxQ7yZaz/F3vuKzivvrGpfGvIrIsMytG8= Date: Wed, 27 Nov 2024 16:58:48 -0800 From: Andrew Morton To: Andrii Nakryiko Cc: linux-mm@kvack.org, urezki@gmail.com, hch@infradead.org, vbabka@suse.cz, dakr@kernel.org, mhocko@suse.com, linux-kernel@vger.kernel.org, bpf@vger.kernel.org, ast@kernel.org Subject: Re: [PATCH mm/stable] mm: fix vrealloc()'s KASAN poisoning logic Message-Id: <20241127165848.42331fd7078565c0f4e0a7e9@linux-foundation.org> In-Reply-To: <20241126005206.3457974-1-andrii@kernel.org> References: <20241126005206.3457974-1-andrii@kernel.org> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: A7F23100003 X-Rspam-User: X-Stat-Signature: ic9zcjn51bqshysnzwmfzuo1zb89r5mf X-HE-Tag: 1732755518-680409 X-HE-Meta: U2FsdGVkX1/MvamNywATNQRVGRyPvYvFG5JhmJ4pEHt/ZKM9PzeY+aBwqYqonpbNqi6qaFCadaqObuNDuGR17UM1CB1GFMUUAClfOrJB1VgdQJmoriZJl0i2p24eWRw2LWY0dUglVmtwb0bo/e+gOnvDrk6TSn19YuZbEiBVeHlWIjveDPApspXIv0NsXbK0DKXM1iwOq+bnQEkvt7os5hnX1fhfmB4US8qhWIDWlKjbCJbAG3YY5eywE2DZ+qmhSNqq0HmmEnh/3UFQ2bICajy/20RRuf3FCYvDFLs53xQqEWbmyL6E1UXfPzmAd37RxKmd8ADB7ZGvNpmI6spH0E4vSZcmq0LDSL93cqsRKCYXQevM/vjxIhoPZz0VyxSIZwMDbYlGRQ96mdsdBQtMbHcuDBy/Fg+ccBY8BZESsQ8ZVCrNEkW8VEJrnQ3w9sAz+k18pUikUc4WBov9m+QN3r96M4TXb5Js/N5G9TCQfkU1eyoAmUdyRm6KqLkafqR+tTkRuM5HFqZ/89Y9nkj5wJgcDuPwcqvaBwRaRhAL+nIHccFQSHDYX4l7PZSjTYt1P8LgBS4ymkCyTNb/Ccauc8rf/yJs1XX+9HnQs4iskO/xahgiHQkrJAL6ynByN1iMizpWxEcuh4PBnqqZtlQqp8dxBD+hYWZmW9qbTFDxV8QBkywkAOSIXjBjcHpFU8dVgU8oqnkLUt7wTtPLuRh4UhoBg1G4D9oh77+8VOmmnXf0Dp/WBHR+PlrF3QpzNJKPxRqP5HwmBCYs62JjWZlF+dGaDafe/leQGWjRS+zssBBLG9gL5qqJKtJunp08VizLcUc99eOncfTGPdkXeuqg6eATRUW90SLom7YTbPPuIJXIR50cI5DvLGBD3Q3KxDMtNqB2epbRsIxWSxoKGq/faoheNOT8c8CHxQB14+dU77rrDbKu9iRnih/bDwxDSA4Nwmo/1wZZrzJVXwqjtdB vRMkPjI/ gTZ3J4gzMiJpCtiyVfV3r9TULnFy/qXAvalih5wPxSnvlhu9N4JGMRUb0TXN6CiNU8BBU4lYRQX7AklN0xHSkbxLV9vg9KLRgD9H8D7hC1Xv4i+cQftAogU63LB+9EkLVj2oKo/5j6bzcI8DBp1HMBp/pEywxjfXfoFV32gvNbw6jjI7xMqyLSfCCCZcXMcT/QlJw5FEq5uHNzSU8Nh88WrditicE3DDBBZEBJFflAlkZieocaN6GcoOXAKE3ugCWAA2YbELnqKljN1I= 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: List-Subscribe: List-Unsubscribe: On Mon, 25 Nov 2024 16:52:06 -0800 Andrii Nakryiko wrote: > When vrealloc() reuses already allocated vmap_area, we need to > re-annotate poisoned and unpoisoned portions of underlying memory > according to the new size. What are the consequences of this oversight? When fixing a flaw, please always remember to describe the visible effects of that flaw. > Note, hard-coding KASAN_VMALLOC_PROT_NORMAL might not be exactly > correct, but KASAN flag logic is pretty involved and spread out > throughout __vmalloc_node_range_noprof(), so I'm using the bare minimum > flag here and leaving the rest to mm people to refactor this logic and > reuse it here. > > Fixes: 3ddc2fefe6f3 ("mm: vmalloc: implement vrealloc()") Because a cc:stable might be appropriate here. But without knowing the effects, it's hard to determine this. > --- a/mm/vmalloc.c > +++ b/mm/vmalloc.c > @@ -4093,7 +4093,8 @@ void *vrealloc_noprof(const void *p, size_t size, gfp_t flags) > /* Zero out spare memory. */ > if (want_init_on_alloc(flags)) > memset((void *)p + size, 0, old_size - size); > - > + kasan_poison_vmalloc(p + size, old_size - size); > + kasan_unpoison_vmalloc(p, size, KASAN_VMALLOC_PROT_NORMAL); > return (void *)p; > } >