Re: [PATCH] keys: prevent slab cache merging for key_jar

["Vlastimil Babka (SUSE)" <vbabka@kernel.org>]

On 6/8/26 06:22, Jarkko Sakkinen wrote:
> On Thu, Jun 04, 2026 at 01:50:34PM +0100, Mohammed EL Kadiri wrote:
>> 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.

I just realized this part is somewhat misleading, because it's done there
for performance reasons, so I wouldn't say "similar".

> 
> ~/work/kernel.org/jarkko/linux-tpmdd master*
> ❯ git log --oneline -1 d0bf7d5759c1d89fb013aa41cca5832e00b9632a
> d0bf7d5759c1 mm/slab: introduce kmem_cache flag SLAB_NO_MERGE
> 
> ~/work/kernel.org/jarkko/linux-tpmdd master*
> ❯ git describe --contains d0bf7d5759c1d89fb013aa41cca5832e00b9632a
> v6.5-rc1~137^2^3~1
> 
> So we could probably forward to stable's starting from v6.6+ if that
> is necessary / makes sense?

It won't hurt, but I doubt it's "necessary" per stable rules. But stable
maintainers ignore those themselves anyway, so whatever.

> It's not a bug fix but kind of still I think would be a change that
> stable kernels are better off with it than without it.
> 
> What do you think?

Won't object.

>> Signed-off-by: Mohammed EL Kadiri <med08elkadiri@gmail.com>
>> ---
>>  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 = 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);
>>  
>>  	/* add the special key types */
>>  	list_add_tail(&key_type_keyring.link, &key_types_list);
>> -- 
>> 2.43.0
>> 
> 
> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
> 
> BR, Jarkko