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

[Namjae Jeon]

On Mon, Mar 2, 2026 at 11:10 PM Yang Wen <anmuxixixi@xxxxxxxxx> wrote:
>
> On Mon, 2 Mar 2026 18:58:41 Namjae Jeon <linkinjeon@xxxxxxxxxx> 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().
Okay, Do we need to keep the duplicate initialization code in
exfat_inode_init_once()?
Thanks.