From: syzbot <syzbot+4ea6bd8737669b423aae@syzkaller.appspotmail.com>
To: linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com
Subject: Forwarded: [PATCH] ext4: fix missing i_data_sem lock in move_extent repair path
Date: Mon, 08 Dec 2025 04:45:54 -0800 [thread overview]
Message-ID: <6936c882.a70a0220.38f243.00a5.GAE@google.com> (raw)
In-Reply-To: <69368649.a70a0220.38f243.0093.GAE@google.com>
For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.
***
Subject: [PATCH] ext4: fix missing i_data_sem lock in move_extent repair path
Author: kartikey406@gmail.com
#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
ext4_swap_extents() requires both i_data_sem locks to be held, as
enforced by BUG_ON checks at the function entry. However, the
repair_branches error path in mext_move_extent() calls
ext4_swap_extents() without holding these locks.
When mext_folio_mkwrite() fails after a successful extent swap, the
code jumps to repair_branches to restore the original extent mapping.
At this point, i_data_sem has already been released, causing the
BUG_ON in ext4_swap_extents() to trigger.
Fix this by acquiring i_data_sem for both inodes before calling
ext4_swap_extents() in the repair_branches path, matching the
locking pattern used in the normal swap path.
Reported-by: syzbot+4ea6bd8737669b423aae@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=4ea6bd8737669b423aae
Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>
---
fs/ext4/move_extent.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/fs/ext4/move_extent.c b/fs/ext4/move_extent.c
index 0550fd30fd10..635fb8a52e0c 100644
--- a/fs/ext4/move_extent.c
+++ b/fs/ext4/move_extent.c
@@ -393,9 +393,11 @@ static int mext_move_extent(struct mext_data *mext, u64 *m_len)
repair_branches:
ret2 = 0;
+ ext4_double_down_write_data_sem(orig_inode, donor_inode);
r_len = ext4_swap_extents(handle, donor_inode, orig_inode,
mext->donor_lblk, orig_map->m_lblk,
*m_len, 0, &ret2);
+ ext4_double_up_write_data_sem(orig_inode, donor_inode);
if (ret2 || r_len != *m_len) {
ext4_error_inode_block(orig_inode, (sector_t)(orig_map->m_lblk),
EIO, "Unable to copy data block, data will be lost!");
--
2.43.0
prev parent reply other threads:[~2025-12-08 12:45 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-08 8:03 [syzbot] [ext4?] kernel BUG in ext4_swap_extents syzbot
2025-12-08 12:45 ` syzbot [this message]
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=6936c882.a70a0220.38f243.00a5.GAE@google.com \
--to=syzbot+4ea6bd8737669b423aae@syzkaller.appspotmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=syzkaller-bugs@googlegroups.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox