From: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
To: Jiayuan Chen <jiayuan.chen@linux.dev>,
linux-ext4@vger.kernel.org, jack@suse.cz
Cc: Jiayuan Chen <jiayuan.chen@shopee.com>,
Jiayuan Chen <jiayuan.chen@linux.dev>,
Theodore Ts'o <tytso@mit.edu>,
Andreas Dilger <adilger.kernel@dilger.ca>,
Ritesh Harjani <riteshh@linux.ibm.com>,
Ye Bin <yebin10@huawei.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3] ext4: fix use-after-free in update_super_work when racing with umount
Date: Fri, 20 Mar 2026 08:23:16 +0530 [thread overview]
Message-ID: <jyv7xlcz.ritesh.list@gmail.com> (raw)
In-Reply-To: <20260319120336.157873-1-jiayuan.chen@linux.dev>
Jiayuan Chen <jiayuan.chen@linux.dev> writes:
> From: Jiayuan Chen <jiayuan.chen@shopee.com>
>
> Commit b98535d09179 ("ext4: fix bug_on in start_this_handle during umount
> filesystem") moved ext4_unregister_sysfs() before flushing s_sb_upd_work
> to prevent new error work from being queued via /proc/fs/ext4/xx/mb_groups
> reads during unmount. However, this introduced a use-after-free because
> update_super_work calls ext4_notify_error_sysfs() -> sysfs_notify() which
> accesses the kobject's kernfs_node after it has been freed by kobject_del()
> in ext4_unregister_sysfs():
>
> update_super_work ext4_put_super
> ----------------- --------------
> ext4_unregister_sysfs(sb)
> kobject_del(&sbi->s_kobj)
> __kobject_del()
> sysfs_remove_dir()
> kobj->sd = NULL
> sysfs_put(sd)
> kernfs_put() // RCU free
> ext4_notify_error_sysfs(sbi)
> sysfs_notify(&sbi->s_kobj)
> kn = kobj->sd // stale pointer
> kernfs_get(kn) // UAF on freed kernfs_node
> ext4_journal_destroy()
> flush_work(&sbi->s_sb_upd_work)
Yes, the race between kobject_del() and sysfs_notify() -> kernfs_get()
is real.
and sysfs_remove_dir() explicitely says:
* In general, kobject owner is responsible for ensuring removal
* doesn't race with other operations and sysfs doesn't provide any
* protection
Hence this patch which adds a new mutex lock to prevent the above race,
looks good to me. So please feel free to add:
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
next prev parent reply other threads:[~2026-03-20 2:59 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-19 12:03 [PATCH v3] ext4: fix use-after-free in update_super_work when racing with umount Jiayuan Chen
2026-03-19 12:48 ` Jan Kara
2026-03-20 2:53 ` Ritesh Harjani [this message]
2026-03-28 5:31 ` Theodore Ts'o
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jyv7xlcz.ritesh.list@gmail.com \
--to=ritesh.list@gmail.com \
--cc=adilger.kernel@dilger.ca \
--cc=jack@suse.cz \
--cc=jiayuan.chen@linux.dev \
--cc=jiayuan.chen@shopee.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=riteshh@linux.ibm.com \
--cc=tytso@mit.edu \
--cc=yebin10@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.