From nobody Mon Jun 8 05:25:46 2026 Received: from mail-wr1-f44.google.com (mail-wr1-f44.google.com [209.85.221.44]) (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 1D931324B23 for ; Sat, 6 Jun 2026 14:26:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.44 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780755969; cv=none; b=GJ62HqK7oi4Oofu9vmCjRu9S0cRHA0tyCAlV2UHRVZdkryke4my9ogvOY6aHkNyLaxQV11FmpShK6eSZvK1k+YiFW05uhMkam2VuLluHTvZBaTM+cRErEyZsgDZPIHyAeF6yqHEjGxLTbpl0cEQ6ckTBCplEWOY1tkZ8/GMd5uE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780755969; c=relaxed/simple; bh=+hyM4gk1hqjvyfZgMjW1YVTkHIHEHreAZGzkhudju4I=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=p+iObn8YuWzhsHemIMGcOT6dAKcus2faZLwYNF6zeXD8Z1RlFHMOc1N4ulacsWkGnbg6/YmM5mvHij5aNVjwyPkPdQpeSrck1acdYKKadX8SuwSuqBPBVrGxwaOoSfOd4KF5tbWAds7gmuWoOU0KyBi4b3frFqT9HzfP7eT/krI= 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=Bgujt8eh; arc=none smtp.client-ip=209.85.221.44 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="Bgujt8eh" Received: by mail-wr1-f44.google.com with SMTP id ffacd0b85a97d-45ef6565cfdso1325931f8f.0 for ; Sat, 06 Jun 2026 07:26:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1780755966; x=1781360766; 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=Mi3D5Ovx/vc/M3F2YJZvJdLo/rPpgsVFqrneVPAyiLg=; b=Bgujt8eh/e1ASUydDqvSJl5iCcB0vX11xXdNpKXH7ikVYSzxurj5OIHEnrj9TIyE8J 1Sy/ycHlGOFxILB4MUhYdI/axIWzAQcBLkgW1iZYVW7lqGVP55hpJ9DucLWGwIPTpHM8 o9cmaKeUBzq/DjdKB9my5e6ca8dsJghNkMyun11VdgVnxFcMn2QIpxNZ5b2q9FMEiX+4 qelNJRb0JZLYzHGLclBMU8sXuymVAIsimuQE1vXpVuVqGIVrQO/0+L7XhoLgxKw5ZrOi N31eMkIDiWfOy8BmctKxAzr+rCTHmtnNsgJpxdTPXqLwsSmSyjAoidnI1pAZORLw+VH1 RsXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780755966; x=1781360766; 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=Mi3D5Ovx/vc/M3F2YJZvJdLo/rPpgsVFqrneVPAyiLg=; b=Ude69Ym+CCaQiXJ3pVXMumAJ6pOhK6u3UMg0aCLvjvIargNvzvd7o1XJpPnDJH9v3c 5EuMBmkw57jWacPUJJrlTeYx8hceLySR+XhhdP6XVjnmMoe6QGp/GmJsqWpO7wDUSTOZ xFxPPJdUGhScJVDrXHTn+0UDMyhIOOpNOdCKr5ZP4EUV2VmGhb3t7uRawZCbFwGWKHFX HXOwHH22GNmjIDyLtjpdeApeMmIq5V97uwTh5vbU1IPx4DEzWNJHjvawoC+T1LQB8Vho FvmvF6BvkOu0Kn2qW6Ps1BrBDGv1fv6d0vp7zmSC18o1kt8qyCLiEhtedpub+enfEpWb F0DA== X-Forwarded-Encrypted: i=1; AFNElJ+zZSu80NmQY+78Cg+/Z//0gdaxXh1uaECE3X7aFbwEFXZ9n2YbSryyPaou+wkRWyQ4MFNIEGCMiYBwHCM=@vger.kernel.org X-Gm-Message-State: AOJu0YzjYxZN9ct9YmKhet0P1lXz7jt8oynGuUy0WJJQfv2/H+AtD/Xp ZLce4EMZ+6AT2bSSvcQu6XzCMwpQbXWnzVZ5F9MDdy3jgy4/qkq3XRw= X-Gm-Gg: Acq92OHZIUYXFu8lysxtoTsjBKozs67AzJYXxHkdyM7vuu9TQi6bsfcPhDiIOK3reeL /bKrQ/MyAoQcRliy0cknSkZH9Ys+NQz0wJRwaYsxhvjQUSUcUjAKqNxrDSsukTBVh3VLzUZf60R nVxrEwmuaNMIOiASLQLARCGaO/Vl6SUhl6dgyXhW1s9xvWoSbDL9T5GKzcuAJorNm4sEMPQkDTI Fcx+JpSeMbwKV5PuxokBKsAkCLTp9Aity8qSAbqzbUeDf8FnPgf9rjQ3DRuZXZaaQFo9+QCV3q3 bFXxHbXvYEgL01m51A7+zLgsANe119KDvHU9TWIlBgX5fSm1xSiNbDXaY19qGTnwVe0r494boAm Fi1AE9Q3uO610f5m75/u5Q/nIhsT8kFivWCDbhP3QDUXZzfjY1Fes6d0zPk36+KkwDPJbJgNlJc HAq73NeGIRkYuF1irNzscdXT5A2/Ovax3u7NWMrPkNEEUXNcfm2uhUlQkHIP7kfPcQhZhaFszol 2L1IRt03b3ml4+nxgDbnRUlfux7WYJ/KH3UrxGSZg== X-Received: by 2002:a5d:54cc:0:b0:45e:ea9b:edfb with SMTP id ffacd0b85a97d-46030766c2amr9776459f8f.39.1780755966236; Sat, 06 Jun 2026 07:26:06 -0700 (PDT) Received: from hp-ubuntu.. ([196.119.187.57]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4601f344762sm37699842f8f.23.2026.06.06.07.26.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 06 Jun 2026 07:26:05 -0700 (PDT) From: Mohammed EL Kadiri To: Paul Moore Cc: Serge Hallyn , Vlastimil Babka , Kees Cook , linux-security-module@vger.kernel.org, linux-hardening@vger.kernel.org, linux-kernel@vger.kernel.org, Mohammed EL Kadiri Subject: [PATCH] cred: prevent slab cache merging for cred_jar Date: Sat, 6 Jun 2026 15:25:58 +0100 Message-ID: <20260606142558.13809-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 cred_jar slab cache holds struct cred objects, which contain process credentials: uid, gid, euid, egid, and capability sets. Overwriting any of these fields is sufficient for privilege escalation. On a default Ubuntu 6.17.0-23-generic system, cred_jar (named "cred" in sysfs) has 2 aliases, meaning 2 unrelated object types share its slab pages (object_size=3D184, objs_per_slab=3D42). Cross-cache heap exploitation relies on slab cache merging to achieve type confusion between unrelated kernel objects. CVE-2022-29582 demonstrates this technique: an io_uring use-after-free is leveraged across cache boundaries through page-level reallocation, ultimately achieving root. struct cred is a primary target in this class of attacks due to the direct privilege escalation that results from corrupting any of its identity or capability fields. Add SLAB_NO_MERGE to ensure cred_jar receives dedicated slab pages, so that freed credential slots can only be reallocated as struct cred objects. The memory overhead is minimal: one struct cred exists per task, and with 42 objects per slab page, 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) and key_jar (security/keys/key.c) which use SLAB_NO_MERGE for similar isolation requirements. Signed-off-by: Mohammed EL Kadiri --- kernel/cred.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/cred.c b/kernel/cred.c index 9676965c0981..0e4ee60a5acd 100644 --- a/kernel/cred.c +++ b/kernel/cred.c @@ -557,7 +557,7 @@ void __init cred_init(void) { /* allocate a slab in which we can store credentials */ cred_jar =3D KMEM_CACHE(cred, - SLAB_HWCACHE_ALIGN | SLAB_PANIC | SLAB_ACCOUNT); + SLAB_HWCACHE_ALIGN | SLAB_PANIC | SLAB_ACCOUNT | SLAB_NO_MERGE); } =20 /** --=20 2.43.0