[PATCH] cred: prevent slab cache merging for cred_jar

[PATCH] cred: prevent slab cache merging for cred_jar

[Mohammed EL Kadiri]

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=184, objs_per_slab=42).

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 <med08elkadiri@gmail.com>
---
 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 = KMEM_CACHE(cred,
-			      SLAB_HWCACHE_ALIGN | SLAB_PANIC | SLAB_ACCOUNT);
+			      SLAB_HWCACHE_ALIGN | SLAB_PANIC | SLAB_ACCOUNT | SLAB_NO_MERGE);
 }
 
 /**
-- 
2.43.0

Re: [PATCH] cred: prevent slab cache merging for cred_jar

[Kees Cook]

On Sat, Jun 06, 2026 at 03:25:58PM +0100, Mohammed EL Kadiri wrote:
> 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=184, objs_per_slab=42).
> 
> 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 <med08elkadiri@gmail.com>

Yes please. :)

Reviewed-by: Kees Cook <kees@kernel.org>

-- 
Kees Cook

Re: [PATCH] cred: prevent slab cache merging for cred_jar

[Mohammed EL Kadiri]

Hi Kees,

Thanks for the review!
Following Vlastimil and Jarkko's feedback on the key_jar patch, should
I send a v2 here as well with similar commit message modification:
removing CVE references, dropping the skbuff comparison, and framing
it as hardening?

Thanks,
Mohammed

On Wed, Jun 10, 2026 at 9:45 PM Kees Cook <kees@kernel.org> wrote:
>
> On Sat, Jun 06, 2026 at 03:25:58PM +0100, Mohammed EL Kadiri wrote:
> > 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=184, objs_per_slab=42).
> >
> > 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 <med08elkadiri@gmail.com>
>
> Yes please. :)
>
> Reviewed-by: Kees Cook <kees@kernel.org>
>
> --
> Kees Cook

Re: [PATCH] cred: prevent slab cache merging for cred_jar

[Kees Cook]

On Wed, Jun 10, 2026 at 10:07:24PM +0100, Mohammed EL Kadiri wrote:
> Hi Kees,
> 
> Thanks for the review!
> Following Vlastimil and Jarkko's feedback on the key_jar patch, should
> I send a v2 here as well with similar commit message modification:
> removing CVE references, dropping the skbuff comparison, and framing
> it as hardening?

It wouldn't hurt, yeah. I have that kind of already in my head while I
read these patches, but it would be better for other folks to see it
framed more accurately.

-Kees

> 
> Thanks,
> Mohammed
> 
> On Wed, Jun 10, 2026 at 9:45 PM Kees Cook <kees@kernel.org> wrote:
> >
> > On Sat, Jun 06, 2026 at 03:25:58PM +0100, Mohammed EL Kadiri wrote:
> > > 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=184, objs_per_slab=42).
> > >
> > > 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 <med08elkadiri@gmail.com>
> >
> > Yes please. :)
> >
> > Reviewed-by: Kees Cook <kees@kernel.org>
> >
> > --
> > Kees Cook

-- 
Kees Cook