[PATCH] jffs2: fix double-free of f->target in jffs2_alloc_inode()

[PATCH] jffs2: fix double-free of f->target in jffs2_alloc_inode()

[Deepanshu Kartikey]

jffs2_alloc_inode() does not initialize f->target before returning
the new inode. It is normally cleared later by
jffs2_init_inode_info(), called from jffs2_iget(), but that runs
only after alloc_inode() has already returned successfully.

If inode_init_always() fails in between, alloc_inode() calls
->free_inode() directly on the half-initialized inode.
jffs2_free_inode() then does kfree(f->target) on whatever stale
value was left in the reused slab object, which can be a pointer
that was already freed, causing a double-free.

Initialize f->target to NULL in jffs2_alloc_inode() to close this
window, and clear it in jffs2_free_inode() after freeing it so a
reused or re-freed object can never carry a dangling pointer.

Fixes: 4fdcfab5b553 ("jffs2: fix use-after-free on symlink traversal")
Reported-by: syzbot+675e84fdf3dde67b4946@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=675e84fdf3dde67b4946
Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>
---
 fs/jffs2/super.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/fs/jffs2/super.c b/fs/jffs2/super.c
index 81396a092ba8..30d753d4c263 100644
--- a/fs/jffs2/super.c
+++ b/fs/jffs2/super.c
@@ -42,6 +42,7 @@ static struct inode *jffs2_alloc_inode(struct super_block *sb)
 	f = alloc_inode_sb(sb, jffs2_inode_cachep, GFP_KERNEL);
 	if (!f)
 		return NULL;
+	f->target = NULL;
 	return &f->vfs_inode;
 }
 
@@ -50,6 +51,7 @@ static void jffs2_free_inode(struct inode *inode)
 	struct jffs2_inode_info *f = JFFS2_INODE_INFO(inode);
 
 	kfree(f->target);
+	f->target = NULL;
 	kmem_cache_free(jffs2_inode_cachep, f);
 }
 
-- 
2.34.1

Re: [PATCH] jffs2: fix double-free of f->target in jffs2_alloc_inode()

[Deepanshu Kartikey]

On Sun, Aug 23, 2026 at 8:57 PM Deepanshu Kartikey
<kartikey406@gmail.com> wrote:
>
> jffs2_alloc_inode() does not initialize f->target before returning
> the new inode. It is normally cleared later by
> jffs2_init_inode_info(), called from jffs2_iget(), but that runs
> only after alloc_inode() has already returned successfully.
>
> If inode_init_always() fails in between, alloc_inode() calls
> ->free_inode() directly on the half-initialized inode.
> jffs2_free_inode() then does kfree(f->target) on whatever stale
> value was left in the reused slab object, which can be a pointer
> that was already freed, causing a double-free.
>
> Initialize f->target to NULL in jffs2_alloc_inode() to close this
> window, and clear it in jffs2_free_inode() after freeing it so a
> reused or re-freed object can never carry a dangling pointer.
>
> Fixes: 4fdcfab5b553 ("jffs2: fix use-after-free on symlink traversal")
> Reported-by: syzbot+675e84fdf3dde67b4946@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=675e84fdf3dde67b4946
> Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>
> ---
>  fs/jffs2/super.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/fs/jffs2/super.c b/fs/jffs2/super.c
> index 81396a092ba8..30d753d4c263 100644
> --- a/fs/jffs2/super.c
> +++ b/fs/jffs2/super.c
> @@ -42,6 +42,7 @@ static struct inode *jffs2_alloc_inode(struct super_block *sb)
>         f = alloc_inode_sb(sb, jffs2_inode_cachep, GFP_KERNEL);
>         if (!f)
>                 return NULL;
> +       f->target = NULL;
>         return &f->vfs_inode;
>  }
>
> @@ -50,6 +51,7 @@ static void jffs2_free_inode(struct inode *inode)
>         struct jffs2_inode_info *f = JFFS2_INODE_INFO(inode);
>
>         kfree(f->target);
> +       f->target = NULL;
>         kmem_cache_free(jffs2_inode_cachep, f);
>  }
>
> --
> 2.34.1
>

Gentle Reminder. Please let me know the status of this patch.

Thanks

Deepanshu

AW: [PATCH] jffs2: fix double-free of f->target in jffs2_alloc_inode()

[Richard Weinberger]

Am Sat, Sep 12, 2026, 03:08 schrieb Deepanshu Kartikey <kartikey406@gmail.com>:

> On Sun, Aug 23, 2026 at 8:57 PM Deepanshu Kartikey
> <kartikey406@gmail.com> wrote:
> >
> > jffs2_alloc_inode() does not initialize f->target before returning
> > the new inode. It is normally cleared later by
> > jffs2_init_inode_info(), called from jffs2_iget(), but that runs
> > only after alloc_inode() has already returned successfully.
> >
> > If inode_init_always() fails in between, alloc_inode() calls
> > ->free_inode() directly on the half-initialized inode.
> > jffs2_free_inode() then does kfree(f->target) on whatever stale
> > value was left in the reused slab object, which can be a pointer
> > that was already freed, causing a double-free.
> >
> > Initialize f->target to NULL in jffs2_alloc_inode() to close this
> > window, and clear it in jffs2_free_inode() after freeing it so a
> > reused or re-freed object can never carry a dangling pointer.
> >
> > Fixes: 4fdcfab5b553 ("jffs2: fix use-after-free on symlink traversal")
> > Reported-by: syzbot+675e84fdf3dde67b4946@syzkaller.appspotmail.com
> > Closes: https://syzkaller.appspot.com/bug?extid=675e84fdf3dde67b4946
> > Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>
> > ---
> >  fs/jffs2/super.c | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/fs/jffs2/super.c b/fs/jffs2/super.c
> > index 81396a092ba8..30d753d4c263 100644
> > --- a/fs/jffs2/super.c
> > +++ b/fs/jffs2/super.c
> > @@ -42,6 +42,7 @@ static struct inode *jffs2_alloc_inode(struct super_block *sb)
> >         f = alloc_inode_sb(sb, jffs2_inode_cachep, GFP_KERNEL);
> >         if (!f)
> >                 return NULL;
> > +       f->target = NULL;
> >         return &f->vfs_inode;
> >  }
> >
> > @@ -50,6 +51,7 @@ static void jffs2_free_inode(struct inode *inode)
> >         struct jffs2_inode_info *f = JFFS2_INODE_INFO(inode);
> >
> >         kfree(f->target);
> > +       f->target = NULL;
> >         kmem_cache_free(jffs2_inode_cachep, f);
> >  }
> >
> > --
> > 2.34.1
> >
> 
> Gentle Reminder. Please let me know the status of this patch.

We got lot's of identical fixes this issue.
I had no time yet to sort out who was the first.
This is maybe the first report with fix suggestions, but the reporter
vanished:
https://lore.kernel.org/linux-mtd/CAFLxGvyZO_EDo-YM_EybZG3u7aNUoNiThhvbhQCrOPD7mPV6GA@mail.gmail.com/

Thanks,
//richard

Re: [PATCH] jffs2: fix double-free of f->target in jffs2_alloc_inode()

[Deepanshu Kartikey]

On Sat, Sep 12, 2026 at 12:28 PM Richard Weinberger <richard@nod.at> wrote:
>
> Am Sat, Sep 12, 2026, 03:08 schrieb Deepanshu Kartikey <kartikey406@gmail.com>:
>
> > On Sun, Aug 23, 2026 at 8:57 PM Deepanshu Kartikey
> > <kartikey406@gmail.com> wrote:
> > >
> > > jffs2_alloc_inode() does not initialize f->target before returning
> > > the new inode. It is normally cleared later by
> > > jffs2_init_inode_info(), called from jffs2_iget(), but that runs
> > > only after alloc_inode() has already returned successfully.
> > >
> > > If inode_init_always() fails in between, alloc_inode() calls
> > > ->free_inode() directly on the half-initialized inode.
> > > jffs2_free_inode() then does kfree(f->target) on whatever stale
> > > value was left in the reused slab object, which can be a pointer
> > > that was already freed, causing a double-free.
> > >
> > > Initialize f->target to NULL in jffs2_alloc_inode() to close this
> > > window, and clear it in jffs2_free_inode() after freeing it so a
> > > reused or re-freed object can never carry a dangling pointer.
> > >
> > > Fixes: 4fdcfab5b553 ("jffs2: fix use-after-free on symlink traversal")
> > > Reported-by: syzbot+675e84fdf3dde67b4946@syzkaller.appspotmail.com
> > > Closes: https://syzkaller.appspot.com/bug?extid=675e84fdf3dde67b4946
> > > Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>
> > > ---
> > >  fs/jffs2/super.c | 2 ++
> > >  1 file changed, 2 insertions(+)
> > >
> > > diff --git a/fs/jffs2/super.c b/fs/jffs2/super.c
> > > index 81396a092ba8..30d753d4c263 100644
> > > --- a/fs/jffs2/super.c
> > > +++ b/fs/jffs2/super.c
> > > @@ -42,6 +42,7 @@ static struct inode *jffs2_alloc_inode(struct super_block *sb)
> > >         f = alloc_inode_sb(sb, jffs2_inode_cachep, GFP_KERNEL);
> > >         if (!f)
> > >                 return NULL;
> > > +       f->target = NULL;
> > >         return &f->vfs_inode;
> > >  }
> > >
> > > @@ -50,6 +51,7 @@ static void jffs2_free_inode(struct inode *inode)
> > >         struct jffs2_inode_info *f = JFFS2_INODE_INFO(inode);
> > >
> > >         kfree(f->target);
> > > +       f->target = NULL;
> > >         kmem_cache_free(jffs2_inode_cachep, f);
> > >  }
> > >
> > > --
> > > 2.34.1
> > >
> >
> > Gentle Reminder. Please let me know the status of this patch.
>
> We got lot's of identical fixes this issue.
> I had no time yet to sort out who was the first.
> This is maybe the first report with fix suggestions, but the reporter
> vanished:
> https://lore.kernel.org/linux-mtd/CAFLxGvyZO_EDo-YM_EybZG3u7aNUoNiThhvbhQCrOPD7mPV6GA@mail.gmail.com/
>
> Thanks,
> //richard
>

I feel the patch you are pointing at fixes a different kind of issue ?

AW: [PATCH] jffs2: fix double-free of f->target in jffs2_alloc_inode()

[Richard Weinberger]

Am Sat, Sep 12, 2026, 10:00 schrieb Deepanshu Kartikey <kartikey406@gmail.com>:
> On Sat, Sep 12, 2026 at 12:28 PM Richard Weinberger <richard@nod.at> wrote:
> I feel the patch you are pointing at fixes a different kind of issue ?

Well, different symptoms of a common root cause.

Thanks,
//richard

Re: [PATCH] jffs2: fix double-free of f->target in jffs2_alloc_inode()

[Deepanshu Kartikey]

On Sat, Sep 12, 2026 at 10:27 PM Richard Weinberger <richard@nod.at> wrote:
>
> Am Sat, Sep 12, 2026, 10:00 schrieb Deepanshu Kartikey <kartikey406@gmail.com>:
> > On Sat, Sep 12, 2026 at 12:28 PM Richard Weinberger <richard@nod.at> wrote:
> > I feel the patch you are pointing at fixes a different kind of issue ?
>
> Well, different symptoms of a common root cause.
>
> Thanks,
> //richard

Totally understood this. But it is good to have a defensive check so that
there is no dangling pointer. It will prevent future [UAF, double free bugs].

Thanks

Deepanshu

Re: [PATCH] jffs2: fix double-free of f->target in jffs2_alloc_inode()

[Deepanshu Kartikey]

On Sun, Sep 13, 2026 at 8:54 AM Deepanshu Kartikey
<kartikey406@gmail.com> wrote:
>
> On Sat, Sep 12, 2026 at 10:27 PM Richard Weinberger <richard@nod.at> wrote:
> >
> > Am Sat, Sep 12, 2026, 10:00 schrieb Deepanshu Kartikey <kartikey406@gmail.com>:
> > > On Sat, Sep 12, 2026 at 12:28 PM Richard Weinberger <richard@nod.at> wrote:
> > > I feel the patch you are pointing at fixes a different kind of issue ?
> >
> > Well, different symptoms of a common root cause.
> >
> > Thanks,
> > //richard
>
> Totally understood this. But it is good to have a defensive check so that
> there is no dangling pointer. It will prevent future [UAF, double free bugs].
>
> Thanks
>
> Deepanshu

Let me know the status of this patch

Thanks

Deepanshu