On Fri, Jun 05, 2026 at 02:16:00PM +0200, Vlastimil Babka (SUSE) wrote: > On 6/4/26 14:50, 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. > > > > Signed-off-by: Mohammed EL Kadiri <[email protected]> > > Acked-by: Vlastimil Babka (SUSE) <[email protected]>
Thank you. has been applied BR, Jarkko
