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

[Kees Cook <kees@kernel.org>]

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