Re: [PATCH v2] docs/mm/slab: document cache isolation with SLAB_NO_MERGE

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

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 <med08elkadiri@gmail.com>
> ---
> 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
>  ========================
>