The struct slab pointer has been obtained one from the object being
freed on all the paths that lead to this function. In all cases this
already includes the test for slab type of the struct page which struct
slab is overlaying. Thus we would not reach this function if it was
not a valid slab pointer in the first place.

One less obvious case is that kmem_cache_free() trusts virt_to_slab()
blindly so it may be NULL if the slab type check is false. But with
SLAB_CONSISTENCY_CHECKS, cache_from_obj() called also from
kmem_cache_free() catches this and returns NULL, which terminates
freeing immediately.

Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
---
 mm/slub.c | 5 -----
 1 file changed, 5 deletions(-)

diff --git a/mm/slub.c b/mm/slub.c
index 93df6e82af37c798c3fa5574c9d825f0f4a83013..106dbce64acdf32c1d271ec130c35c0ec0e15630 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -3487,11 +3487,6 @@ static inline bool free_debug_processing(struct kmem_cache *s,
 	int cnt = 0;
 
 	if (s->flags & SLAB_CONSISTENCY_CHECKS) {
-		if (!validate_slab_ptr(slab)) {
-			slab_err(s, slab, "Not a valid slab page");
-			goto out;
-		}
-
 		if (!check_slab(s, slab))
 			goto out;
 	}

-- 
2.51.0

On Thu, Sep 11, 2025 at 07:02:39PM +0200, Vlastimil Babka wrote:
> The struct slab pointer has been obtained one from the object being
> freed on all the paths that lead to this function. In all cases this
> already includes the test for slab type of the struct page which struct
> slab is overlaying. Thus we would not reach this function if it was
> not a valid slab pointer in the first place.
> 
> One less obvious case is that kmem_cache_free() trusts virt_to_slab()
> blindly so it may be NULL if the slab type check is false. But with
> SLAB_CONSISTENCY_CHECKS, cache_from_obj() called also from
> kmem_cache_free() catches this and returns NULL, which terminates
> freeing immediately.

Oh, I thought it'll crash even with debug caches
but it won't and I misread the code.

> Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
> ---

Looks good to me,
Reviewed-by: Harry Yoo <harry.yoo@oracle.com>

-- 
Cheers,
Harry / Hyeonggon