From: Heming Zhao <heming.zhao@suse.com>
To: Deepanshu Kartikey <kartikey406@gmail.com>, joseph.qi@linux.alibaba.com
Cc: mark@fasheh.com, jlbec@evilplan.org, akpm@linux-foundation.org,
brauner@kernel.org, jack@suse.cz, zzzccc427@gmail.com,
ericterminal@gmail.com, ocfs2-devel@lists.linux.dev,
christophe.jaillet@wanadoo.fr, linux-kernel@vger.kernel.org,
syzbot+3025e3e8fc0b928af8f5@syzkaller.appspotmail.com
Subject: Re: [PATCH] ocfs2: fix use-after-free in o2hb_region_dev_store
Date: Thu, 24 Sep 2026 18:37:19 +0800 [thread overview]
Message-ID: <arT8GTxhKeGu6cAW@p15> (raw)
In-Reply-To: <20260904235710.16317-1-kartikey406@gmail.com>
On Sat, Sep 05, 2026 at 05:27:10AM +0530, Deepanshu Kartikey wrote:
> Concurrent writes to a region's "dev" attribute can race, letting two
> tasks both allocate/free reg->hr_slot_data for the same region and
> causing a use-after-free. Add a per-region mutex to serialize
> o2hb_region_dev_store() against itself and against
> o2hb_region_release().
Hi,
Did AI generate this patch? The commit log says "reg->hr_slot_data" should be
protected, but the code protects ->hr_bdev_file in o2hb_region_dev_store(), not
o2hb_map_slot_data().
Just code logic, I prefer changing struct mutex hr_dev_write_mutex to hr_mutex.
@Joseph,
I'm not very familiar with the heartbeat, based on the syzbot report, it seems
hr_slot_data needs protection. Does it make sense to fix this in cluster world?
Thanks,
Heming
>
> Fixes: 1d3aa0b97c55 ("ocfs2: port block device access to file")
> Reported-by: syzbot+3025e3e8fc0b928af8f5@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=3025e3e8fc0b928af8f5
> Tested-by: syzbot+3025e3e8fc0b928af8f5@syzkaller.appspotmail.com
> Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>
> ---
> fs/ocfs2/cluster/heartbeat.c | 23 +++++++++++++++++++----
> 1 file changed, 19 insertions(+), 4 deletions(-)
>
> diff --git a/fs/ocfs2/cluster/heartbeat.c b/fs/ocfs2/cluster/heartbeat.c
> index 1c3def99bb07..6f03de1b6d4a 100644
> --- a/fs/ocfs2/cluster/heartbeat.c
> +++ b/fs/ocfs2/cluster/heartbeat.c
> @@ -273,6 +273,9 @@ struct o2hb_region {
>
> /* last hb status, 0 for success, other value for error. */
> int hr_last_hb_status;
> + /* Serializes dev_store() against itself and region_release() */
> + struct mutex hr_dev_write_mutex;
> +
> };
>
> static inline struct block_device *reg_bdev(struct o2hb_region *reg)
> @@ -1616,7 +1619,10 @@ static void o2hb_region_release(struct config_item *item)
>
> o2hb_quiesce_timeout(reg);
> o2net_unregister_and_flush_handler_list(®->hr_handler_list);
> +
> + mutex_lock(®->hr_dev_write_mutex);
> o2hb_unmap_slot_data(reg);
> + mutex_unlock(®->hr_dev_write_mutex);
>
> if (reg->hr_bdev_file)
> fput(reg->hr_bdev_file);
> @@ -1879,9 +1885,6 @@ static ssize_t o2hb_region_dev_store(struct config_item *item,
> ssize_t ret = -EINVAL;
> int live_threshold;
>
> - if (reg->hr_bdev_file)
> - return -EINVAL;
> -
> /* We can't heartbeat without having had our node number
> * configured yet. */
> reg->hr_node_num = o2nm_this_node();
> @@ -1906,12 +1909,20 @@ static ssize_t o2hb_region_dev_store(struct config_item *item,
> if (!S_ISBLK(fd_file(f)->f_mapping->host->i_mode))
> return -EINVAL;
>
> + if (mutex_lock_interruptible(®->hr_dev_write_mutex))
> + return -ERESTARTSYS;
> +
> + if (reg->hr_bdev_file) {
> + ret = -EINVAL;
> + goto out_unlock;
> + }
> +
> reg->hr_bdev_file = bdev_file_open_by_dev(fd_file(f)->f_mapping->host->i_rdev,
> BLK_OPEN_WRITE | BLK_OPEN_READ, NULL, NULL);
> if (IS_ERR(reg->hr_bdev_file)) {
> ret = PTR_ERR(reg->hr_bdev_file);
> reg->hr_bdev_file = NULL;
> - return ret;
> + goto out_unlock;
> }
>
> sectsize = bdev_logical_block_size(reg_bdev(reg));
> @@ -2029,6 +2040,8 @@ static ssize_t o2hb_region_dev_store(struct config_item *item,
> fput(reg->hr_bdev_file);
> reg->hr_bdev_file = NULL;
> }
> +out_unlock:
> + mutex_unlock(®->hr_dev_write_mutex);
> return ret;
> }
>
> @@ -2149,6 +2162,8 @@ static struct config_item *o2hb_heartbeat_group_make_item(struct config_group *g
>
> config_item_init_type_name(®->hr_item, name, &o2hb_region_type);
>
> + mutex_init(®->hr_dev_write_mutex);
> +
> /* this is the same way to generate msg key as dlm, for local heartbeat,
> * name is also the same, so make initial crc value different to avoid
> * message key conflict.
> --
> 2.34.1
>
>
next prev parent reply other threads:[~2026-09-24 10:37 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-04 23:57 [PATCH] ocfs2: fix use-after-free in o2hb_region_dev_store Deepanshu Kartikey
2026-09-23 3:26 ` Deepanshu Kartikey
2026-09-24 10:37 ` Heming Zhao [this message]
2026-09-24 12:07 ` Joseph Qi
2026-10-01 8:23 ` Deepanshu Kartikey
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=arT8GTxhKeGu6cAW@p15 \
--to=heming.zhao@suse.com \
--cc=akpm@linux-foundation.org \
--cc=brauner@kernel.org \
--cc=christophe.jaillet@wanadoo.fr \
--cc=ericterminal@gmail.com \
--cc=jack@suse.cz \
--cc=jlbec@evilplan.org \
--cc=joseph.qi@linux.alibaba.com \
--cc=kartikey406@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mark@fasheh.com \
--cc=ocfs2-devel@lists.linux.dev \
--cc=syzbot+3025e3e8fc0b928af8f5@syzkaller.appspotmail.com \
--cc=zzzccc427@gmail.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.