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 9124DC2BA18 for ; Thu, 20 Jun 2024 23:29:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 015828D00F4; Thu, 20 Jun 2024 19:29:31 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id F10938D00EC; Thu, 20 Jun 2024 19:29:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DCF048D00F4; Thu, 20 Jun 2024 19:29:30 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id C066A8D00EC for ; Thu, 20 Jun 2024 19:29:30 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 545C71C0FFF for ; Thu, 20 Jun 2024 23:29:30 +0000 (UTC) X-FDA: 82252860900.03.AC384AB Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf12.hostedemail.com (Postfix) with ESMTP id A04254000B for ; Thu, 20 Jun 2024 23:29:28 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=vI7naTbg; spf=pass (imf12.hostedemail.com: domain of kees@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=kees@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1718926163; 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=TAs1wJjgRFBQkuDDst6VdaEQ00/oRztxpfcsXc1W4X0=; b=ks5Bur6Oz9huaKiIagVkXG7FgugLKYw1l0RTTexZPn3IUoleqvGSxf0kG9gnfv+GqiR7Vu tID/BUzlUIASxZccy8jxPsml74bOQM+6hz9hyQ+OxXpd/O+gqIrlG4qxUZ+MPyJxJG4/fe v/swv5zGR7BhOVBnqNfMvLEK9sGrIPg= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=vI7naTbg; spf=pass (imf12.hostedemail.com: domain of kees@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=kees@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1718926163; a=rsa-sha256; cv=none; b=KQ5B0uEyhOyqi1wt5TURgFa+hAKv6WGuyeytFJSUkxafRejfJ+lhtqqUu3xt9RzeJVK84b UgLQ47Tde+arm/jOw1kXQMUwqeOaEPsWT/DIY4ieNxw2noIOlygAlFmSMTE7WnI6ml4t+c e5C6HuIIZCNSihBfCnQIKinPzsQFe2M= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 905E362363; Thu, 20 Jun 2024 23:29:27 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 41F06C2BD10; Thu, 20 Jun 2024 23:29:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1718926167; bh=/sadit87DkhqYLioSkOH0TfD3gxDb0YHnkI1SLYBgSw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=vI7naTbg3JsloxxZ0TMaMBhRn9jCCMpzIRnnznh402AZg3Xjtbw9aAv3Durp4e++N taLRY6lqcGpI1Ve7YymtUQJd1ok8eitlLBVT0IguNvLTOxSiuVgNbJnkPGOwcnDnBx EJ8v+kEyT53Mf/pFzMO+hLRctCONcinjlkTUs6/e+TAdagrQHu3jvLnshX9Ja5DjFb J/D8B3X2ItjVP7lO+HxFDgX1g5+VcNQbV7vedmGH0NX3tMcf69SJa87Jthbxrs6HP3 lTmmfVBhhlC3KxY2yeJJ4wHNyP5trc7njZLla/AsmKfUs/ROEQKWS0E08t5ovG63an fVLl49P474idA== Date: Thu, 20 Jun 2024 16:29:26 -0700 From: Kees Cook To: Andi Kleen Cc: Vlastimil Babka , "GONG, Ruiqi" , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , jvoisin , Andrew Morton , Roman Gushchin , Hyeonggon Yoo <42.hyeyoo@gmail.com>, Xiu Jianfeng , Suren Baghdasaryan , Kent Overstreet , Jann Horn , Matteo Rizzo , Thomas Graf , Herbert Xu , linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-hardening@vger.kernel.org, netdev@vger.kernel.org Subject: Re: [PATCH v5 4/6] mm/slab: Introduce kmem_buckets_create() and family Message-ID: <202406201620.0392F7E45@keescook> References: <20240619192131.do.115-kees@kernel.org> <20240619193357.1333772-4-kees@kernel.org> <87r0crut6v.fsf@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87r0crut6v.fsf@linux.intel.com> X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: A04254000B X-Stat-Signature: grtn93z9niwtnod1qba1ssjwwrqarpmg X-Rspam-User: X-HE-Tag: 1718926168-854294 X-HE-Meta: U2FsdGVkX1+roZl8LY/KMmJrqAEb0rV09sq6tW6+EVaEOJKp/wtlXN9mvr2Z/jApHdfeOh5yjGeoymcTeu6g+MEhN/RM661SmpRC652bQfDZCcer0+M3lEp9dL4EWPrIx/zRwL+OGjSsp75c/EmypQrBREh0ksVKYoJgiBr9+K1SrFT5xp8D6ze9JNJk3d8nuh47hQDDQWrUmQrAyapWqSJlZGyOXbbg8mAdf4Pjg0hEslqjYxCXjHGr7RLQfREf9PuW3JYU54m5/tk8y0V2uLLgaB871T4mKEfToCCI/4O2cgprze+NLPgTYtyZrslwoWc7feNvS7k7cF8Rvf13rPE8XMm3eXOrtSYwFwTR9arjbG+wBL2BgI/b+K5EHb8aKx41R04GgqgxOgM+1tuQZXVU9DHNwWt2/B2ZLrQ+YEMgY8SLQczBDNCIJCQyifSD+4S07gBSya/O6ZJ0om3dd2DvTB7dJbQ+NmB/gIn2VkNrNK59G/UbOGfLnuAYtpxI4ROHvN/+q3HZqTCqbztp4E1EKKh6nNq6gIr1OCsc1V7jTk6z9ujJBSqt1KP0r55so1VnUDAhN/Zcri7jdXUgPRTfW7T/Z6AHEkryInhAW7yCGiiO+23wVM8yfVwCj72aB6/c/v9TKZiciQG8mt4iO48ibw6UxHE+toxeT2J+lz7V9CxxqnACcoHMBiQrzk6rvrwlCFIDIexm10j2xIi6Mj2uRGRjLBVHOsqBTFYDhfHNpos1e43O4Ba4lNVvYp0vBIBxjDvCJ/l2Z9jC7/h17UPywdvgHB6z24vXaqQJ9bS7qCKQ8RJR8C2q1tvMuw/I3lSUr67r+ZzvNRn+YfrOtc0gPeAX49G6+PbaRse3OddjrCVQtF17EA2PNg6/x3ujzMoTtPFhMSf3TIAfqsKTXME2CODMX64L8iuLsQnao7qVpeRLI2Bhpxw2k2Ok+Z46gRRucHorvMJmBDDhN+H RxwxSeR8 M66oLsoW/pGj38rbjaia+D0Hetjur96+LjiV/XOuUHv8b5bQj2QqL8RhAzzCca0/e2R8lpW+Iwb/IemuBSOT4EoQI8vPhVd8mbXEpEFU4vzB8Pc8T1q1T1bKfCHViUkM3n4g8q2EV5ud0q6OwAc8Oi+IDyJbaqKLXng+vkQFkkoA7IMl1SbqipQ7s2Yr4mLeslLNs9ZQOTnDVwXhaCLymBk5sxdA7yqcpHK+vljQ7cXiMR4F3+JZWwcwS9RLz7TLaR87DFnMei0R1z3M8A4ilcLK8H8/lRog8Up8tmp/jrR+VSQjcnl86jDZrvk35TU6WAmJAJlFO/6YgaVK6i/Im4cR0hNQPTfXv//liv4GWC9LvHlGVtEa9qixDfYpG85OBQLx5B7QNPuO7AbaaqZx4TCDN1mKXfIYFPHPDFO/M3dzhNOzjRNN1FSl5o3PfXS2Lrfpo+vRqlaURP5Psi7/ysuXL/CtzAOH+LSv19Vnpt0+6E7PnSLgMnAzg5IhGi7BrBcPF 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 Thu, Jun 20, 2024 at 03:48:24PM -0700, Andi Kleen wrote: > Kees Cook writes: > > > Dedicated caches are available for fixed size allocations via > > kmem_cache_alloc(), but for dynamically sized allocations there is only > > the global kmalloc API's set of buckets available. This means it isn't > > possible to separate specific sets of dynamically sized allocations into > > a separate collection of caches. > > > > This leads to a use-after-free exploitation weakness in the Linux > > kernel since many heap memory spraying/grooming attacks depend on using > > userspace-controllable dynamically sized allocations to collide with > > fixed size allocations that end up in same cache. > > > > While CONFIG_RANDOM_KMALLOC_CACHES provides a probabilistic defense > > against these kinds of "type confusion" attacks, including for fixed > > same-size heap objects, we can create a complementary deterministic > > defense for dynamically sized allocations that are directly user > > controlled. Addressing these cases is limited in scope, so isolating these > > kinds of interfaces will not become an unbounded game of whack-a-mole. For > > example, many pass through memdup_user(), making isolation there very > > effective. > > Isn't the attack still possible if the attacker can free the slab page > during the use-after-free period with enough memory pressure? > > Someone else might grab the page that was in the bucket for another slab > and the type confusion could hurt again. > > Or is there some other defense against that, other than > CONFIG_DEBUG_PAGEALLOC or full slab poisoning? And how expensive > does it get when any of those are enabled? > > I remember reading some paper about a apple allocator trying similar > techniques and it tried very hard to never reuse memory (probably > not a good idea for Linux though) > > I assume you thought about this, but it would be good to discuss such > limitations and interactions in the commit log. Yup! It's in there; it's just after what you quoted above. Here it is: > > Memory allocation pinning[2] is still needed to plug the Use-After-Free > > cross-allocator weakness, but that is an existing and separate issue > > which is complementary to this improvement. Development continues for > > that feature via the SLAB_VIRTUAL[3] series (which could also provide > > guard pages -- another complementary improvement). > > [...] > > Link: https://googleprojectzero.blogspot.com/2021/10/how-simple-linux-kernel-memory.html [2] > > Link: https://lore.kernel.org/lkml/20230915105933.495735-1-matteorizzo@google.com/ [3] Let me know if you think this description needs to be improved... -Kees -- Kees Cook