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 9EA18C19F53 for ; Sun, 28 Apr 2024 11:03:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0B8916B0088; Sun, 28 Apr 2024 07:03:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 069376B0089; Sun, 28 Apr 2024 07:03:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E72A86B008A; Sun, 28 Apr 2024 07:03:10 -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 C78CE6B0088 for ; Sun, 28 Apr 2024 07:03:10 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 8DECC1A141D for ; Sun, 28 Apr 2024 11:02:59 +0000 (UTC) X-FDA: 82058653278.01.29EADC8 Received: from out-174.mta1.migadu.com (out-174.mta1.migadu.com [95.215.58.174]) by imf29.hostedemail.com (Postfix) with ESMTP id 461EC120019 for ; Sun, 28 Apr 2024 11:02:55 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=dustri.org header.s=key1 header.b=LJ0ZG0CV; spf=pass (imf29.hostedemail.com: domain of julien.voisin@dustri.org designates 95.215.58.174 as permitted sender) smtp.mailfrom=julien.voisin@dustri.org; dmarc=pass (policy=quarantine) header.from=dustri.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1714302175; 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=pVVFme9IGZxZcwcArhmhbXXpkSUt5435Tn6KlathRfY=; b=yq1+plNdmbTwPch5tLBQSjd5ifsQF4KwovmHwpL1mpuEtcO+LDuNNsY8wZ73cr5ct85d9H RDByPHWXeaAYMXuCuR/TaJHMf0yt5e8shRyM5rf/gcKR4fQGv9nKefOiMbnu09uCXSbzD3 K08Eob8CHehZMOAeUHapkfDvonx8qBg= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=dustri.org header.s=key1 header.b=LJ0ZG0CV; spf=pass (imf29.hostedemail.com: domain of julien.voisin@dustri.org designates 95.215.58.174 as permitted sender) smtp.mailfrom=julien.voisin@dustri.org; dmarc=pass (policy=quarantine) header.from=dustri.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1714302175; a=rsa-sha256; cv=none; b=N7/eZw7O7kBKwnsly9pzbId13l8Y6ScvdPBQVsG3DuF/GAvQ2drqx3nl+RULOhKxTyeD7/ Q5AJojf2Ghu+5e+F2XxNGovf1Y+IgM9jxYm7s3CJyzLPdLbkPQ9knMhEGUGPkmbWb7Fnyd vRveLS49h1z9HwXJCYOYQnlUYZ1LOdw= Message-ID: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dustri.org; s=key1; t=1714302171; h=from:from: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:autocrypt:autocrypt; bh=pVVFme9IGZxZcwcArhmhbXXpkSUt5435Tn6KlathRfY=; b=LJ0ZG0CVcsv9NBeC7oXAVzCp8DNIyDjzDzpmJwgI+ywplahcnxaBpn6DOV4eAcdYC803TS 6ctEcHggsNJkFsxrmE5eu64AmZ3nLKIJw+j0pv1hHuEKlLiDww4vPfXxFcUiSDv75SXONE 6vLeQEjumyb6fpYAZ6b96TTa1c04BazYBfIcUkKEUoJiYKSAd5NJWLBHvT2HSaAfwEQaSB +lfODkoOzH0jfX/Vu8glrcTLMn1mT5upZel7u3B7iqMd6PJGU1WxlRn1SkXfMKrp/YdXsD 7cSjyKQcAd338B5vRoSE8fJhRocVcVH7CE2+fPrpiZA4uAkYhWeC79hXJcOhmQ== Date: Sun, 28 Apr 2024 13:02:36 +0200 MIME-Version: 1.0 Subject: Re: [PATCH v3 0/6] slab: Introduce dedicated bucket allocator To: Kees Cook , Vlastimil Babka Cc: Andrew Morton , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Roman Gushchin , Hyeonggon Yoo <42.hyeyoo@gmail.com>, "GONG, Ruiqi" , 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 References: <20240424213019.make.366-kees@kernel.org> Content-Language: en-US X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: jvoisin Autocrypt: addr=julien.voisin@dustri.org; keydata= xsFNBFWzxaABEACu3G1fwzHtrhHuotgvZ69zA4YqF9vYfx7hoYrjnKzP5pTiOZ2US6AJj1qE W1WlN6cHnqzzqoXotVu/MPuPrbadL21jRnJWurrkktpcqK4BaCZ5S0lOQ3ck40LysidexhI6 ZZi6jhBZzuzxs2Mi9aIPIxDekXAWQBybs4m27E4MNmJkIshVnDTMQ4ToGQxzwPj+VurpQVPh WGMCPwlUbVkN/w6N/lLC088ePpESh5E0vFE+BQc66ZpRn+cXTlaqjQnwRtWuEBoqJSn2MXAn wODEj4H5HvQjgFyRfmOHHMTEHOg4yyc84SmIv8YJlTbVX7VnMGUJF43SA4PFtXFypBkQ481u w10XdBPYwD/i0q3QnzzRiIsrlQJUCkGFxyIpcDNRnf3ApjT4+QuEaw98tKvgRzCozFx2D94w sSFz858vZrdYj4pt/VYw8JeoPDiWwuzPVvgpJmQlL8aCRnAhLIv9O+fySvXcGh1WEvtUgkNn 1WjU2M00BYnPNFBEeGMRWkxuVwV1o+WKNJfwg2UcDghSkJGBCPCAiC2fDlfyk3njjLjxZHP/ mYNwUkxTlQolzknJZ5wg7vbE6r4rfQX4gTi3mNzYtqUAb17GIczOARZK7qdSapObrXPFGgX3 Bd4FZJEaIq3p5xWcWS8fcMveoYO7m9cyaSkSQxAPrPZE3hDF1QARAQABzTJKdWxpZW4gKGp2 b2lzaW4pIFZvaXNpbiA8anVsaWVuLnZvaXNpbkBkdXN0cmkub3JnPsLBlwQTAQoAQQIbAwUL CQgHAwUVCgkICwUWAgMBAAIeAQIXgAIZARYhBJ/N7p4aOB8xHqYqdATQQegXGQHMBQJfDWXp BQkSV5eAAAoJEATQQegXGQHMKrwQAI8gOcx3qRk7T5qBgg9rlk3WDaJWcmw1Dq2VnjKrEVLh vxvwK/CjiaH4g6oUiGNeDVBoozjzKM/umHL7SoBjhHiayEu33ziAjLWxiVGbHVmHmfXkZdQz CEBSI1ZR8HF88tFCCOCtK7Nc+1yohmTnfnrIIEXMpSvAgdFilwnjYbaNe+aQ9MJMo+k7J144 h+BzN5EW19zVwOidUdD0HxKpCYz6D34etnYIpv8Qa0KBzOPTtO1QYr6A7MfQPiRVlIOA543g h9bi9SQhCBsOZU1NOVQUZ3/ktj8qlUTVlOhGKYaPvJJ0X9va02rzL7zxYcVZgQic2dTLGYW/ GGHVseegnxWB/7V49Yf4ZljQvjK2B1COmahZ2UYN+fzqXO0NhpSLX4SDKDnvM/3X2TYWx1MS fY8x4IURA633TTW9QZzflqIYk4aO44/8MDiuaxLwt+e6d8EN8ECaAoVFPCq1dWTjCJ4XhSlb 6eV8trCpLZfkVviuRD7xPtZU1sViVSj/O9naQ2HuUq0+LuYBmI25BEpq2rkgVKS++sYgUtxO IP5WoQJeNNnS+8e15VRdb77WxRe6+05JNu48wZI2OcW/MiyFs+cGtoDC5mSpVuJTmpPumP7A hjlxy4e5YlQn6coqQcuNL1DC/vUFwO1/cnh5dqk0x5JfHL1/XFWYjsVNjuJj/vIQzsFNBFWz xaABEAC/p5ESSIlC6qVJnxfhtIpappjkHmFjMHWmFrB05KnmtGB/InGH0e5y2OVaKz0RErLd f2CAzU5zb9cyLPnqHpE7SaqtPBmahTBX7nVzIFrbjLpU/XPHaWrHa6M1ifyu1y2msXe5U1ln oOVjJXTVsyoNAt8wzf73I4St2+pY7kQBlv5AUTssa4T22hZs3BImcd4OsLpct2aIGd3NGofN ksiLB3ZiE/vKJkXWIbx9/hm8nuKlQuHGo+sHho8T+QQcc+YCo66BYBznzD+yEv/UALjgHWU/ PXw3RVM8kqQ3WlmWsYKqQYgkaA2cVPrkbLlxiHg28Y4deu6oZR4oSovXjJk4jj3m/UckaN0f c47BG1VwKVHxjg/c8hy1elunhJv0Vf2eLA6pc0UfAcpSkJZNkOLjFZ9YROHdiKiUE4pEej4/ o3WE76TIX58aURuouVAVwe14sIED3QLoO+4wczTZsOX/jcOg2D2qPquby5taOAM6yPP/v7fy TAG9UYdxq1L9/wKwhH1pmagkTmLu7k5XzgQ/6rrR4NJPRRMETrtqDFJNb2UxhRlnl/Cavkt6 5BK7D0QJ9n9phFWC2oTIaMd5suFZK3I71UdeTaBOlrqmqLzuBVhzQeAK2vaJI1c6IzqjGRlx PEm6BuHfRWaf+LLj4Z7wrupWwAxLjHgPUCL2Chk2ZwARAQABwsF8BBgBCgAmAhsMFiEEn83u nho4HzEepip0BNBB6BcZAcwFAl8NaJcFCRK/pHcACgkQBNBB6BcZAcxUhg//fmeZNMlB7NPJ bT4dLsnSTCRAl1zqCxqowPyG4ux79qiG73KW/vLT1EUQTm4ANyl5Mwyf+3ssfzxl/Flp7i93 57rENZRMWj80JluU8w68sUrxKlTNZfrukHttoNPmTh9TTuvP0yQXysJyy0p6VvdBT5euf2Iw LMERoaln4h2VuhLSL80VcJfou0TVl9Aq47HerwTPXQdC4Rm/bYrdDdZhEJMrEQuDP6eLIjmC 4vI51LwnPcXABan3WudfEaxdpI9acwcCy9XQ32vIjhxV9D3fx0dsfo6PDXFdKEY9q+bfOjUt GyqZWRtqe/EWM8T1w4H4svpGpTh2mB8Du/1jNy5CiSgLiDySd6Gz8vP0rqFGYuLN1fCBNpd4 PzF29dPO8xJ++K5pVi+pXpKzIfW9f2ZL0fabrsKP1Rht+q+3ldgGSvgw3v2aFffvEuRmodiY Vkby7UMuABQGlgE89z+cffBRhelgNzoVs/PtIuWb/y5BgOBGD9zUn4Z2FjB5eby230qkP1uQ +vyunBj6QnANa7qBxycL+xXbW8HBksArQ/HX+OZs7hagrP0qGMnjmCzsblv0wixghgvQTkpg 61RTH34ieLUkzE0oFkrqJyNZcoH0wStdP/9zwK1Av0cZcFcvlLdIL956v4IpZozW1ScG7OJw 766VTOg4l2PTPCnIdNFy1Os= In-Reply-To: <20240424213019.make.366-kees@kernel.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Migadu-Flow: FLOW_OUT X-Stat-Signature: 56i5fd3eeiywyf7mcszfjs1z3dggrpjo X-Rspam-User: X-Rspamd-Queue-Id: 461EC120019 X-Rspamd-Server: rspam05 X-HE-Tag: 1714302175-455247 X-HE-Meta: U2FsdGVkX1/tOrt5YR/FmXsrw3J6HTHzNzirMG+A7q75OXxeqhVhvbNb9CdsWTqaQc04dI/kkgYDfcFMuR+pvHkCwA4p3Fr1YqoctLnAge5bEzVT0cz2joWlAOKXD2CvJ9nvjBXJlJV+q9ApdRqNGCZb9VwOA/j5TnPefuBVq08n2723sX1BqFpIWq0GHnsa1QZLjMPZj8m8/g7a+L5pGOSH/8HAQHng9nAloMQEHPlUEAD+uzr7CHTQpOLzsBvv/pBEMp8JhMCV2nbEsazutQLoH9V37/m6Qo7dpM5UbAJqdai+khVK4YUdjRVkci5ikYFgXYvnQHDN13Th7dDTs+2bpuK7XpMOPAVS/z69asoh/bX8HiXDkDL5rRM24U48Sq0TtpfY38U6eaDOQwQkfarKUzU3LwHiYIlDt4IBFMmoIlVpr0UZRMZtIJyT/1Lk9gNBtZyDrByuI0pE8JiwdFzntd6llq2ClE46ZJNRjUAMfRd2zIlCnfKH7Qfaflxns62p18R1xL8ExUyvauiICCsmax1cW0d6V45OvYrPTFTeDRiQhuoS9dB2OG3k2BJc0s8YcvCWECqkQRWnCJarIj6YKxqOKgmKCn4H8l5+bw/+htI37Zh3HAXNSiWzj/2qkArPF0XtXRkBwTMCHUtlOFicHrQC6D3aEH0yI+bIYn6ReUJyW1+PnqnKmYH1mGKNONpgXevO7DBkr6S8XFSCZVTUF6GeI8o6DXbrGkc2Be8LIGEMRBIozCHNWW8bNBjHImkEIqXBWMpwIFKAIv6FCjqj76JjbEAcFC6P3jHo9kGHmJ4VXEMH2KgF7gnjIthYy5+664VvfEX6zoC7jWYelrI7bvwDlGh3AqQ6/SkG/7hIVRumkoD/M/dIZMpWdU0QW/7k1R/Z1vJXU3hzOeEr96f9Qpf6CTGzid4BPUDqNkrfozJF2NGtjrgpakd/VL4EjzcWolkPhwpFi6FWO38 gyuGfGqH zw2K5gmvBPbJmF5HpRns42ZcI9qRKKIUE9tnO28UTsOSKRKx7Rct/g3pW3+0/ixXZp84R2h64Mq/azMGQERXWnH/deEtbfZ1c6X/KZAFmhA2lm8XjsZrkaxGA1eYe5jliVZZgHxF97Uc36Yu7GXMAFszgv+4kbUH3oMEIN7YemanNMM2cRP5PQAa6u32Ktt0247O4MBqq5ydyvPLdpqrjO+uiBEem5ECa1TU/9xGpzDsvMxmLE+FaiuODsJQLNeRuwZWJF35pa9AY/DCHlShlIXZcN7muZjmWytfnif93CkPC0e3ICgJg/b17fTo5ug+KieLcJmaYrQshu1lJuj2MgPkHokqfkyX9RdHkt9V1TQtHn6Y86iKj7o5Wnus9gp9Y5gZMiuvrQT2P+lJGPPrH+qgyWHF5NCqptayN7jKI0eFOLERq287I/6nLeBbM8GQUuLWBylPbQgtDz96y2mCJ47jtcbevVIcdV7FtS2Q7gvwwsT507bOcttTcAnap4qb3cDJXhS1I9/sRG3fmdiMTzxKpTdlw2JaQg2skhP1oDceTW0Puze3R8WsiYmSPV9hYfJNSpS4GleLd3Jmhjtmas+cRDyRJ+Nk6ZvLzThWH6OACPNvHRvh/Eo6OUr8ZYW2nlgWANdzggKrizBQwg8cykes7ZIPabtCMicl9zReSdFIzzXwnmfCWwnemgvmnGS5L8zfOrbFSuY6t5zbw4XzTQjbyFMJ9j+r7bWbT6sf1jWLQJczpEkPXiqCRMhSuJVow/SAekPdj5/UycUQzGpe0oOpQq/C68ewPG019FeyJNqP9nO9FEtn2H5/L6FlIFNUBndsEDI6JWdubaESqaS28gEkgtvzPlliUVTQ1Yj8W/GtIOi5vefZGVZhT1iJL5qwR8krfH7hI+C9mhkiVAdnZU9GfGTJkPDKsQliVrTXeciLW2uE1onXpyWSDqI19+O+tNSdb0mPpNqGHGOAsN8ofNUxvqmHc qROLzPtd DwjEeTZqwEsuYJziOKaJFu0IVQGl7tXzudSOcedK/js2fksMn4i3vYJfN7XOi6x9fBQHUWljkBEUVNutczwI6hNvs1b+xKg/kTMyjwkq0B0EI/+1FpLnuxNY6PyYlvpBltdiBE0CwKe8i2imxHcoOMOFzCo9PxyAEhZCz9AtC/2kHC7vQj8DNg== 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 4/24/24 23:40, Kees Cook wrote: > Hi, > > Series change history: > > v3: > - clarify rationale and purpose in commit log > - rebase to -next (CONFIG_CODE_TAGGING) > - simplify calling styles and split out bucket plumbing more cleanly > - consolidate kmem_buckets_*() family introduction patches > v2: https://lore.kernel.org/lkml/20240305100933.it.923-kees@kernel.org/ > v1: https://lore.kernel.org/lkml/20240304184252.work.496-kees@kernel.org/ > > For the cover letter, I'm repeating commit log for patch 4 here, which has > additional clarifications and rationale since v2: > > 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 isolation these > kinds of interfaces will not become an unbounded game of whack-a-mole. For > example, pass through memdup_user(), making isolation there very > effective. What does "Addressing these cases is limited in scope, so isolation these kinds of interfaces will not become an unbounded game of whack-a-mole." mean exactly? > > In order to isolate user-controllable sized allocations from system > allocations, introduce kmem_buckets_create(), which behaves like > kmem_cache_create(). Introduce kmem_buckets_alloc(), which behaves like > kmem_cache_alloc(). Introduce kmem_buckets_alloc_track_caller() for > where caller tracking is needed. Introduce kmem_buckets_valloc() for > cases where vmalloc callback is needed. > > Allows for confining allocations to a dedicated set of sized caches > (which have the same layout as the kmalloc caches). > > This can also be used in the future to extend codetag allocation > annotations to implement per-caller allocation cache isolation[1] even > for dynamic allocations. Having per-caller allocation cache isolation looks like something that has already been done in https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3c6152940584290668b35fa0800026f6a1ae05fe albeit in a randomized way. Why not piggy-back on the infra added by this patch, instead of adding a new API? > 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://lore.kernel.org/lkml/202402211449.401382D2AF@keescook [1] > 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] To be honest, I think this series is close to useless without allocation pinning. And even with pinning, it's still routinely bypassed in the KernelCTF (https://github.com/google/security-research/tree/master/pocs/linux/kernelctf). Do you have some particular exploits in mind that would be completely mitigated by your series? Moreover, I'm not aware of any ongoing development of the SLAB_VIRTUAL series: the last sign of life on its thread is from 7 months ago. > > After the core implementation are 2 patches that cover the most heavily > abused "repeat offenders" used in exploits. Repeating those details here: > > The msg subsystem is a common target for exploiting[1][2][3][4][5][6] > use-after-free type confusion flaws in the kernel for both read and > write primitives. Avoid having a user-controlled size cache share the > global kmalloc allocator by using a separate set of kmalloc buckets. > > Link: https://blog.hacktivesecurity.com/index.php/2022/06/13/linux-kernel-exploit-development-1day-case-study/ [1] > Link: https://hardenedvault.net/blog/2022-11-13-msg_msg-recon-mitigation-ved/ [2] > Link: https://www.willsroot.io/2021/08/corctf-2021-fire-of-salvation-writeup.html [3] > Link: https://a13xp0p0v.github.io/2021/02/09/CVE-2021-26708.html [4] > Link: https://google.github.io/security-research/pocs/linux/cve-2021-22555/writeup.html [5] > Link: https://zplin.me/papers/ELOISE.pdf [6] > Link: https://syst3mfailure.io/wall-of-perdition/ [7] > > Both memdup_user() and vmemdup_user() handle allocations that are > regularly used for exploiting use-after-free type confusion flaws in > the kernel (e.g. prctl() PR_SET_VMA_ANON_NAME[1] and setxattr[2][3][4] > respectively). > > Since both are designed for contents coming from userspace, it allows > for userspace-controlled allocation sizes. Use a dedicated set of kmalloc > buckets so these allocations do not share caches with the global kmalloc > buckets. > > Link: https://starlabs.sg/blog/2023/07-prctl-anon_vma_name-an-amusing-heap-spray/ [1] > Link: https://duasynt.com/blog/linux-kernel-heap-spray [2] > Link: https://etenal.me/archives/1336 [3] > Link: https://github.com/a13xp0p0v/kernel-hack-drill/blob/master/drill_exploit_uaf.c [4] What's the performance impact of this series? Did you run some benchmarks? > > Thanks! > > -Kees > > > Kees Cook (6): > mm/slab: Introduce kmem_buckets typedef > mm/slab: Plumb kmem_buckets into __do_kmalloc_node() > mm/slab: Introduce __kvmalloc_node() that can take kmem_buckets > argument > mm/slab: Introduce kmem_buckets_create() and family > ipc, msg: Use dedicated slab buckets for alloc_msg() > mm/util: Use dedicated slab buckets for memdup_user() > > include/linux/slab.h | 44 ++++++++++++++++-------- > ipc/msgutil.c | 13 +++++++- > lib/fortify_kunit.c | 2 +- > lib/rhashtable.c | 2 +- > mm/slab.h | 6 ++-- > mm/slab_common.c | 79 +++++++++++++++++++++++++++++++++++++++++--- > mm/slub.c | 14 ++++---- > mm/util.c | 21 +++++++++--- > 8 files changed, 146 insertions(+), 35 deletions(-) >