From nobody Mon Jun 8 08:52:46 2026 Received: from mail-wm1-f50.google.com (mail-wm1-f50.google.com [209.85.128.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id F21C6477E35 for ; Thu, 4 Jun 2026 12:50:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.50 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780577444; cv=none; b=bO/CNPPG9SWXqrzK+p9iwtDded4SI2WKMpuMJlCW+gqfXWx5ZpGLkwp9gro6f8pB+6mXhl2MJvmIlFbZFob5d1A3iKH9OnRkXnFAEnUyaurw+Rb4278RuqShFx2Va59dxSfEqJGPcvXhkf2Im95zSN3dBDZ/8ScuMBb2HMq7qq4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780577444; c=relaxed/simple; bh=lbWaJXCgqnU/VgUH+gDEW7qnj7gIAwhY6UiysV4cJx8=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=es3fDUGNnkvLX3FjTikuYJa8i3AcIAij/Z9s1uqJZmwTYng5JQQm0daU8sgWQrfFlSg7EWbrtfBO4asdacJHM0r8Lqf1kf8nJLqU5oIPpqOreKixFwhiDoNjPsVOkIBSPGVVrtgiErAq+giVDLu05Kci3/D+qlus5qiiCEJYzbk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=hSt/cjYD; arc=none smtp.client-ip=209.85.128.50 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="hSt/cjYD" Received: by mail-wm1-f50.google.com with SMTP id 5b1f17b1804b1-490b613a17bso6666165e9.3 for ; Thu, 04 Jun 2026 05:50:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1780577439; x=1781182239; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=yJUnjTUV8BBZlgR8+Wodn126IIs4cN704iHM3h+CNdk=; b=hSt/cjYDrt0VUY0x8IFugiSHQesyJJpVAl1T18S5ylZRJj3qjV5UU9oRYfBFxBvX+3 Qog0d8Ft6nXAh5nPnUf9515yyNySi3ZJOE6AJx7/ko8KZH7DzP2FsqX6Dlu9EJ0mGx+Y 1qeQk/vB/0C0mtIXx2uorWG9q6Bfuc/1rkKzzVzC4I8RESGqfqUNYj1v/e5Zsqn2q0fB B2iN9qcR00JS0iSAuRsk/kpn6Sp8C9aBP/HwLyzdhXePrB/bYYZAtT4JLpRza7C8KiEz TdKPwfuxg1bimXLoBmibiksQegVNLLEVgAwXb97rOcYK7N2C9ycRlNacOhBtZG6DVQrw n/9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780577439; x=1781182239; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=yJUnjTUV8BBZlgR8+Wodn126IIs4cN704iHM3h+CNdk=; b=P3Mflgp7WAikU02BWcjeluWNzxqKMK6G0JaHQmOm2FfJSMmQKYT/Z7vNbZb2bZRFUb uuaXFYBhjJ0Vvef0Q07EejXZjuMN4CV8CWb8F0YMbI9/fWfUteRrQpUEW1oRtGcxCt1Y u4GgsWECaBfxOCm0pjZducA5QjV0RxlQ4Z854i63HiYyvvyj2ug1ZNWcNBjY77mo+gSl Kmtn8trx7Bfedg/LR5PijOvYZAlQFZVYvCBbpZWpscqTZEk6LLTM380X5mpWbrw8OfkC yM5V9Tum0VX0LNbUPECFUcW8Oi6bAQXzokJBJh9rBzyqrvmDwxwZ+Lh1oGRCkaZy/edZ jCYA== X-Forwarded-Encrypted: i=1; AFNElJ/WZVCfrLL1Q8J62LbJCMGvnaOnM70Yh82u1wlV3UI7oTJl/CBkAH7QIjKAEd+eTUDo1qEEteCqViTg8PU=@vger.kernel.org X-Gm-Message-State: AOJu0YykDCaGJNLXZbQyUCxA3AK4CdqYAedqHxgoV+alwKKmdPZz0voq e4ojh784EDMDUfGTxkkjEZEI+2Ak7p4gJ0HtKGKQPU5MrePFUH/JqPw= X-Gm-Gg: Acq92OHqVa55aO1agZqJCvDl6/36VSU0kVlmK3/j75qsqDl6jJQcJinP14iqBo27ffD QQnUwBizpPQtx2Bmzj00ZeDwux2ctNHANXpIugQ/5VIzL8BQCwcJcYY4Bj6pxnVfHm1iLV0G1nj o5hQDK2NREv4OqM5jp6v9v6ZoeVLql0if9DS1a0pe/kBEM+nlR2YFiSXDNgS2Vc5LRh8pwuvr2D UaGom38KoBtrsbaJb0X7T9Y/f4iiqdOyhDDZSK9mjvOhbzL2xLDljjhPx9HAqsCD0RVSFIrPreF Oredu0UvnIqyXwNDrR+nEMnEE0qg3HoMFMfl/+RGVkY79LNQ9/geHjnvgy+KpO5u0TqteuZcVX1 2fn0ZIQDRx6+ZasqPwpCYe9zWWylvfFSJdmcmyfxhF51gmJpB2113dJCIzxABo+88cC3VuW+Y8Q Vmk3NFrdDrcFb9l6RGVnm7SI6rGpmskkddXOK7vpRhpaE+t3vcLNm/68y3t3r2DMD0YxcgsBxxd AYRF9efRdxzZ4GtpODcbz4C7fqr5nRTFVKFBS0Q+g== X-Received: by 2002:a05:600c:3487:b0:490:b6a4:9f43 with SMTP id 5b1f17b1804b1-490b6a4a040mr116278425e9.7.1780577439015; Thu, 04 Jun 2026 05:50:39 -0700 (PDT) Received: from hp-ubuntu.. ([196.119.187.57]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-490bc3b59f0sm79430055e9.2.2026.06.04.05.50.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 04 Jun 2026 05:50:38 -0700 (PDT) From: Mohammed EL Kadiri To: David Howells , Jarkko Sakkinen Cc: Paul Moore , James Morris , "Serge E . Hallyn" , Kees Cook , Vlastimil Babka , keyrings@vger.kernel.org, linux-security-module@vger.kernel.org, linux-hardening@vger.kernel.org, linux-kernel@vger.kernel.org, Mohammed EL Kadiri Subject: [PATCH] keys: prevent slab cache merging for key_jar Date: Thu, 4 Jun 2026 13:50:34 +0100 Message-ID: <20260604125034.13757-1-med08elkadiri@gmail.com> X-Mailer: git-send-email 2.43.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" The key_jar slab cache holds struct key objects containing cryptographic keys, authentication tokens, and keyring linkage. This cache currently lacks merge prevention, allowing the SLUB allocator to merge it with other similarly-sized caches. On a default Ubuntu 6.17.0-23-generic system, key_jar has 5 aliases, meaning 5 unrelated object types share its slab pages. struct key is 224 bytes, placed in 256-byte slabs alongside biovec-16, maple_node, ip6_dst_cache, task_delay_info, and kmalloc-256 users. Cross-cache heap exploitation is a well-documented attack class (CVE-2022-29582, CVE-2022-2588, CVE-2021-22555) where slab cache merging enables type confusion between unrelated kernel objects. A use-after-free in any subsystem sharing slab pages with key_jar could allow an attacker to reclaim a freed slot as a struct key, or corrupt an existing key through a dangling pointer to a different type. Add SLAB_NO_MERGE to ensure key_jar receives dedicated slab pages, eliminating cross-cache attacks targeting struct key. The memory overhead is minimal: with 32 objects per slab page and typical key usage bounded by system keyring size, the cost of dedicated pages is negligible. There is zero performance impact on the allocation hot path. This follows the precedent set by skbuff_head_cache (net/core/skbuff.c) which uses SLAB_NO_MERGE for similar isolation requirements. Signed-off-by: Mohammed EL Kadiri Acked-by: Vlastimil Babka (SUSE) Reviewed-by: Jarkko Sakkinen --- security/keys/key.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/security/keys/key.c b/security/keys/key.c index 3bbdde778631..592b65cf8539 100644 --- a/security/keys/key.c +++ b/security/keys/key.c @@ -1275,7 +1275,7 @@ void __init key_init(void) { /* allocate a slab in which we can store keys */ key_jar =3D kmem_cache_create("key_jar", sizeof(struct key), - 0, SLAB_HWCACHE_ALIGN|SLAB_PANIC, NULL); + 0, SLAB_HWCACHE_ALIGN | SLAB_PANIC | SLAB_NO_MERGE, NULL); =20 /* add the special key types */ list_add_tail(&key_type_keyring.link, &key_types_list); --=20 2.43.0