Re: [PATCH] exfat: initialize caching fields during inode allocation

[Yang Wen <anmuxixixi@gmail.com>]

On Mon, 2 Mar 2026 18:58:41 Namjae Jeon <linkinjeon@kernel.org> wrote:

> >diff --git a/fs/exfat/super.c b/fs/exfat/super.c
> >index 83396fd265cd..0c4a22b8d5fa 100644
> >--- a/fs/exfat/super.c
> >+++ b/fs/exfat/super.c
> >@@ -195,6 +195,10 @@ static struct inode *exfat_alloc_inode(struct super_block *sb)
> >        if (!ei)
> >                return NULL;
> >
> >+       spin_lock_init(&ei->cache_lru_lock);
> >+       ei->nr_caches = 0;
> >+       ei->cache_valid_id = EXFAT_CACHE_VALID + 1;
> >+       INIT_LIST_HEAD(&ei->cache_lru);
> These fields are already initialized in exfat_inode_init_once().
> Please check exfat_inode_init_once().
> Thanks.

Thanks for your replay. While it's true that exfat_inode_init_once()
initializes these fields, that constructor is only invoked when the
slab object is first created.

In the case of inode reuse (when an object is freed to the slab cache
and subsequently re-allocated), the fields inherit stale values from
the previous user of that memory block. If an eviction occurs before
these fields are re-initialized by the new owner,
__exfat_cache_inval_inode() sees a non-empty list due to stale
pointers, leading to a NULL pointer dereference.

We have recently observed kernel panics on mobile devices, which were
traced back to a NULL pointer dereference in list_del_init()
within __exfat_cache_inval_inode().

Thanks.