On 6/7/26 09:06, Mohammed EL Kadiri wrote: > Add documentation to slab.rst explaining when and how to use > SLAB_NO_MERGE to protect security-critical slab caches from > cross-cache heap exploitation. > > The document covers: > - When to use SLAB_NO_MERGE and what it communicates > - How to verify merge status on a running system > - Tradeoffs (memory cost vs performance) > - Relationship to CONFIG_RANDOM_KMALLOC_CACHES, SLAB_TYPESAFE_BY_RCU, > and the slab_nomerge boot parameter > > Assisted-by: Claude:claude-opus-4.6 > Signed-off-by: Mohammed EL Kadiri <[email protected]> > --- > Changes in v2 (per Jonathan Corbet and Matthew Wilcox feedback): > - Add content to existing slab.rst instead of creating new file > - Fix markup: use plain function() without additional formatting > - Use slab terminology consistently, not SLUB > - Remove How merging works section (implementation internals) > - Remove cross-cache attack class section (redundant) > - Remove Bounded allocation volume criteria > - Rephrase unmergeability guidance per Matthew Wilcox suggestion > - Add Assisted-by tag per coding-assistants.rst > Documentation/mm/slab.rst | 60 +++++++++++++++++++++++++++++++++++++++ > 1 file changed, 60 insertions(+) > > diff --git a/Documentation/mm/slab.rst b/Documentation/mm/slab.rst > index 2bcc58ada302..c485bd257c44 100644 > --- a/Documentation/mm/slab.rst > +++ b/Documentation/mm/slab.rst > @@ -4,6 +4,66 @@ > Slab Allocation > =============== > > +Cache isolation with SLAB_NO_MERGE > +=================================== > + > +The slab allocator merges caches with compatible size, alignment, and flags > +to reduce memory fragmentation. While this improves memory efficiency, it > +allows objects of different types to share the same slab. This enables > +cross-cache heap exploitation, where a use-after-free in one object type can > +be leveraged to corrupt an unrelated type. > + > +SLAB_NO_MERGE prevents a cache from being merged, ensuring it receives a > +dedicated slab. A freed slot in an isolated cache can only be reallocated as > +the same object type. > + > +When to use SLAB_NO_MERGE > +-------------------------- > + > +SLAB_NO_MERGE should be considered for caches holding security-critical > +objects whose corruption leads directly to privilege escalation, such as > +credentials, cryptographic keys, or capability sets. > + > +It is harmless to specify SLAB_NO_MERGE even if the cache is already > +unmergeable for other reasons (e.g., it has a constructor or a non-zero > +usersize). The flag communicates intent and ensures the cache remains > +isolated if those other properties change in the future. > + > +Verifying merge status > +----------------------- > + > +To check whether a cache is merged on a running system:: > + > + # Check how many other caches share its slab > + cat /sys/kernel/slab/<cache_name>/aliases > + > + # aliases > 0 means other types share this cache's slab > + > +Tradeoffs > +---------- > + > +**Memory**: Isolated caches may have partially-filled slabs that cannot be > +used by other types. The overhead is typically a few extra pages. > + > +**Performance**: Zero impact on kmem_cache_alloc() and kmem_cache_free(). > +The only effect is at boot when the cache is created. > + > +Relationship to other mitigations > +---------------------------------- > + > +CONFIG_RANDOM_KMALLOC_CACHES creates multiple copies of each kmalloc size > +class and randomly assigns allocations among them. It only affects kmalloc() > +users and does not affect named caches created with kmem_cache_create(). > + > +SLAB_TYPESAFE_BY_RCU delays freeing the slab by an RCU grace period. It > +does not delay object slot reuse and does not prevent cross-cache merging. > +It solves a different problem: safe lockless access to freed-and-reallocated > +objects of the same type. > + > +The slab_nomerge boot parameter disables merging for all caches globally. > +SLAB_NO_MERGE provides the same protection selectively for individual caches > +without the global memory cost.
Matthew already pointed out in v1 that these last 2 are unnecessary. I think this is approach unproductive, sorry. IIUC a newcomer to the community, with help of a LLM (I however appreciate the openness about it, with Assisted-by: tag), but multiple senior people have to provide input to hopefully make it into an acceptable shape. This SLAB_NO_MERGE flag isn't that crucial to go through all of this. We could just add a comment about security use cases to the comment above #define SLAB_NO_MERGE and that's it. So please considers other ways of getting involved in the community (which is otherwise welcome), as this is not a great one. Thanks. > + > Functions and structures > ======================== >
