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 2AFF9FA3741 for ; Mon, 31 Oct 2022 15:40:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A94416B0080; Mon, 31 Oct 2022 11:40:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A44428E0005; Mon, 31 Oct 2022 11:40:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 90C318E0003; Mon, 31 Oct 2022 11:40:56 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 6F69B6B0080 for ; Mon, 31 Oct 2022 11:40:56 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id E478A80D43 for ; Mon, 31 Oct 2022 15:40:55 +0000 (UTC) X-FDA: 80081657670.07.C4C90EE Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf28.hostedemail.com (Postfix) with ESMTP id E2734C0021 for ; Mon, 31 Oct 2022 15:40:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=W0IxW07wGXfhbxB2t/U5m54gfxyvIPwy+2kvZkeZYCE=; b=UoMTE4fjFILoU9dWuD24Mpq1Cr X7plBmzOKe2nijiZ3IRKHkM6DGiKraDXfGZSMldphtKA52TEdWcvtPGn8jhsXaIB9NnJkJULCx/0a Gabp3e0nNm89mj0YkmqUUH99d0DeNLJDvhF7psO5GCZY+zHPd9gzRpGFWsbGWfIMpzeOJv9sy9E3w vIlbRhqyo+ef2RpQ1CgUTGIIDCv5LN5vA7kJzVoD68eR5e1aXAEP2Oh5df2p16K6v3LgL6OVlcuZ9 W/dgL1qDNoBIDI4aKrC6NZ5vF4NFV+q/tr8/h74NcUDKHsH6k/pEy5n4NgoR8FugxF6DHzeG1t8sx XViht4uA==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1opWu7-003muP-Qk; Mon, 31 Oct 2022 15:40:47 +0000 Date: Mon, 31 Oct 2022 15:40:47 +0000 From: Matthew Wilcox To: Kees Cook Cc: Vlastimil Babka , Anders Roxell , kernel test robot , Andrew Morton , David Rientjes , Marco Elver , Vincenzo Frascino , linux-mm@kvack.org, Andrey Konovalov , linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org Subject: Re: [PATCH v4] mempool: Do not use ksize() for poisoning Message-ID: References: <20221028154823.you.615-kees@kernel.org> <20221031105514.GB69385@mutt> <13c4bd6e-09d3-efce-43a5-5a99be8bc96b@suse.cz> <202210310821.9F7AA27D12@keescook> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <202210310821.9F7AA27D12@keescook> ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=UoMTE4fj; spf=none (imf28.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1667230854; a=rsa-sha256; cv=none; b=7ZTQJzeNaOOKankT3goTGjfz9803qfkY4dMuZhrZ+WqLfhiTl/53vBBEwGqmhBf9u28MJW OvD7+et8iG/Q1pGCbfdYxNlL4ZbpIqcweOM2FQxVkMbTIeAz8zNfkicpYI2cjJ+eTN+EiR eIRL8DLTiHt8Sg6uuagw5Rj43VRCcMU= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1667230854; 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=W0IxW07wGXfhbxB2t/U5m54gfxyvIPwy+2kvZkeZYCE=; b=uw3TTK2ahMOVPyPy02NF6dlMLxwSKQgmbfarirJDwkd15yoG31v7L9WYCvK5igG8QaZwaM Nb3QHCRZa4X+nfIR8WRNFHl7tMhmgcq123h2YBCE1c/S0IbNP78Kst8k/v3cQ36Le3Agzr h/AjqxEodc7dUu7hDlCQJOBpC1jp5+M= X-Rspam-User: X-Rspamd-Queue-Id: E2734C0021 Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=UoMTE4fj; spf=none (imf28.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none X-Stat-Signature: 9g6bwde4qkr71hhxqojiw7duo33rsbi5 X-Rspamd-Server: rspam10 X-HE-Tag: 1667230853-937633 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 Mon, Oct 31, 2022 at 08:22:50AM -0700, Kees Cook wrote: > On Mon, Oct 31, 2022 at 03:12:33PM +0000, Matthew Wilcox wrote: > > On Mon, Oct 31, 2022 at 04:00:25PM +0100, Vlastimil Babka wrote: > > > +++ b/mm/mempool.c > > > @@ -57,8 +57,10 @@ static void __check_element(mempool_t *pool, void *element, size_t size) > > > static void check_element(mempool_t *pool, void *element) > > > { > > > /* Mempools backed by slab allocator */ > > > - if (pool->free == mempool_free_slab || pool->free == mempool_kfree) { > > > + if (pool->free == mempool_kfree) { > > > __check_element(pool, element, (size_t)pool->pool_data); > > > + } else if (pool->free == mempool_free_slab) { > > > + __check_element(pool, element, kmem_cache_size(pool->pool_data)); > > > } else if (pool->free == mempool_free_pages) { > > > /* Mempools backed by page allocator */ > > > int order = (int)(long)pool->pool_data; > > > > I had a quick look at this to be sure I understood what was going on, > > and I found a grotesque bug that has been with us since the introduction > > of check_element() in 2015. > > > > + if (pool->free == mempool_free_pages) { > > + int order = (int)(long)pool->pool_data; > > + void *addr = kmap_atomic((struct page *)element); > > + > > + __check_element(pool, addr, 1UL << (PAGE_SHIFT + order)); > > + kunmap_atomic(addr); > > > > kmap_atomic() and friends only map a single page. So this is all > > nonsense for HIGHMEM kernels, GFP_HIGHMEM allocations and order > 0. > > The consequence of doing that will be calling memset(POISON_INUSE) > > on random pages that we don't own. > > Ah-ha! Thank you both! Seems like the first fix should be squashed and > the latter one is separate? Or just put it all together? Yes, I have no objection to Vlastimil's patch as-is. I haven't really reviewed it, just used it as an excuse to look at this code. A fix for the kmap_atomic() problem will necessarily be separate and should be backported separately.