For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.
***
Subject: [PATCH] xfs: take hm->lock around __xfs_healthmon_insert() callers
Author: kartikey406@gmail.com
#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
__xfs_healthmon_insert() asserts that hm->lock is held, but both of
its callers invoked it without the lock held:
- xfs_ioc_health_monitor() inserted the initial RUNNING event right
after allocating hm, before ever taking the lock.
- xfs_healthmon_unmount() inserted the UNMOUNT event on an already
published, shared hm without locking it, racing against
concurrent event producers on the same monitor.
Take hm->lock around both calls.
Reported-by: syzbot+ccdf3469f5f653bff7ac@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=ccdf3469f5f653bff7ac
Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>
---
fs/xfs/xfs_healthmon.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/fs/xfs/xfs_healthmon.c b/fs/xfs/xfs_healthmon.c
index 4521ffdab9f1..762f4ce820c8 100644
--- a/fs/xfs/xfs_healthmon.c
+++ b/fs/xfs/xfs_healthmon.c
@@ -415,8 +415,10 @@ xfs_healthmon_unmount(
* There's nothing actionable for userspace after an unmount. Once
* we've inserted the unmount event, hm no longer owns that event.
*/
+ mutex_lock(&hm->lock);
__xfs_healthmon_insert(hm, hm->unmount_event);
hm->unmount_event = NULL;
+ mutex_unlock(&hm->lock);
xfs_healthmon_detach(hm);
xfs_healthmon_put(hm);
@@ -1213,7 +1215,9 @@ xfs_ioc_health_monitor(
}
running_event->type = XFS_HEALTHMON_RUNNING;
running_event->domain = XFS_HEALTHMON_MOUNT;
+ mutex_lock(&hm->lock);
__xfs_healthmon_insert(hm, running_event);
+ mutex_unlock(&hm->lock);
/*
* Preallocate the unmount event so that we can't fail to notify the
--
2.43.0