[syzbot] [ext4?] kernel BUG in ext4_write_inline_data_end (3)

[syzbot] [ext4?] kernel BUG in ext4_write_inline_data_end (3)

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:    a13c140cc289 Linux 7.2-rc3
git tree:       git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-kernelci
console output: https://syzkaller.appspot.com/x/log.txt?x=11d48789580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=ecdef466b08b9772
dashboard link: https://syzkaller.appspot.com/bug?extid=293a57918b36cfae3d48
compiler:       Debian clang version 22.1.8 (++20260613092233+e80beda6e255-1~exp1~20260613092250.77), Debian LLD 22.1.8
userspace arch: arm64
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=16e444b9580000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/b40dd0e99ac8/disk-a13c140c.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/7ef230d7959b/vmlinux-a13c140c.xz
kernel image: https://storage.googleapis.com/syzbot-assets/a593476d5c20/Image-a13c140c.gz.xz
mounted in repro: https://storage.googleapis.com/syzbot-assets/172c5a39071b/mount_0.gz
  fsck result: OK (log: https://syzkaller.appspot.com/x/fsck.log?x=12e444b9580000)

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+293a57918b36cfae3d48@syzkaller.appspotmail.com

------------[ cut here ]------------
kernel BUG at fs/ext4/inline.c:815!
Internal error: Oops - BUG: 00000000f2000800 [#1]  SMP
Modules linked in:
CPU: 1 UID: 0 PID: 20668 Comm: syz.0.3283 Not tainted syzkaller #0 PREEMPT 
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/02/2026
pstate: 83400005 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--)
pc : ext4_write_inline_data_end+0x8fc/0x9d8 fs/ext4/ext4.h:3790
lr : ext4_has_inline_data fs/ext4/ext4.h:3790 [inline]
lr : ext4_write_inline_data_end+0x8fc/0x9d8 fs/ext4/inline.c:815
sp : ffff800090e575c0
x29: ffff800090e57670 x28: dfff800000000000 x27: ffff7000121caebc
x26: 0000000000000000 x25: ffff0000e01554b0 x24: fffffdffc3c2a340
x23: ffff800090e575e0 x22: 0000000000000023 x21: 0000000600080000
x20: ffff0000e01556a0 x19: 0000000000000023 x18: 0000000000000000
x17: 0000000000000000 x16: 0000000000000000 x15: 00000000200000c0
x14: 0000000000000000 x13: 0000000000000001 x12: 0000000000000000
x11: 0000000000000000 x10: ffff60001c02aa97 x9 : 0000000000000000
x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000
x5 : 0000000000000000 x4 : 0000000000000000 x3 : ffff8000810066e8
x2 : 0000000000000000 x1 : ffff0000c4c28000 x0 : 0000000000000000
Call trace:
 ext4_has_inline_data fs/ext4/ext4.h:3790 [inline] (P)
 ext4_write_inline_data_end+0x8fc/0x9d8 fs/ext4/inline.c:815 (P)
 ext4_write_end+0x320/0x9e0 fs/ext4/inode.c:1455
 ext4_da_write_end+0x90/0xba0 fs/ext4/inode.c:3297
 generic_perform_write+0x504/0x7a4 mm/filemap.c:4379
 ext4_buffered_write_iter+0xd0/0x2ec fs/ext4/file.c:316
 ext4_file_write_iter+0x1dc/0x134c fs/ext4/file.c:-1
 new_sync_write fs/read_write.c:595 [inline]
 vfs_write+0x51c/0xa0c fs/read_write.c:687
 ksys_write+0x12c/0x228 fs/read_write.c:739
 __do_sys_write fs/read_write.c:750 [inline]
 __se_sys_write fs/read_write.c:747 [inline]
 __arm64_sys_write+0x7c/0x90 fs/read_write.c:747
 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]
 invoke_syscall+0x98/0x244 arch/arm64/kernel/syscall.c:49
 el0_svc_common+0xec/0x23c arch/arm64/kernel/syscall.c:121
 do_el0_svc+0x4c/0x5c arch/arm64/kernel/syscall.c:140
 el0_svc+0x64/0x260 arch/arm64/kernel/entry-common.c:736
 el0t_64_sync_handler+0x48/0x148 arch/arm64/kernel/entry-common.c:755
 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:594
Code: c8097f28 35ffffa9 17fffe38 97d939e6 (d4210000) 
---[ end trace 0000000000000000 ]---


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title

If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.

If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)

If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report

If you want to undo deduplication, reply with:
#syz undup

Forwarded: [PATCH] ext4: fix race condition in ext4_write_end() with inline data conversion

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: [PATCH] ext4: fix race condition in ext4_write_end() with inline data conversion
Author: kartikey406@gmail.com

#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-kernelci

A race condition exists between ext4_write_end() checking for inline data
and the inline-to-block conversion path clearing the inline flags.

Thread A (write completion):
  - Checks ext4_has_inline_data(inode) = TRUE (no lock held)
  - Checks EXT4_STATE_MAY_INLINE_DATA = TRUE (no lock held)

Thread B (conversion via mmap/readahead):
  - Acquires i_data_sem write lock
  - Clears EXT4_INODE_INLINE_DATA flag
  - Clears EXT4_STATE_MAY_INLINE_DATA state
  - Releases i_data_sem

Thread A (resumes):
  - Calls ext4_write_inline_data_end()
  - BUG_ON(!ext4_has_inline_data(inode)) fails
  - Kernel crashes

The fix is to acquire i_data_sem read lock in ext4_write_end() around
the inline data check and handler, serializing against the conversion
path which holds the write lock.

Reported-by: syzbot+293a57918b36cfae3d48@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?extid=293a57918b36cfae3d48
Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>
---
 fs/ext4/inode.c | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index ce99807c5f5b..9a5347907685 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -1450,11 +1450,17 @@ static int ext4_write_end(const struct kiocb *iocb,
 
 	trace_ext4_write_end(inode, pos, len, copied);
 
+	down_read(&EXT4_I(inode)->i_data_sem);
+	/* Serialize against inline data conversion (see ext4_convert_inline_data_nolock) */
 	if (ext4_has_inline_data(inode) &&
-	    ext4_test_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA))
-		return ext4_write_inline_data_end(inode, pos, len, copied,
+	    ext4_test_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA)) {
+		ret = ext4_write_inline_data_end(inode, pos, len, copied,
 						  folio);
+		up_read(&EXT4_I(inode)->i_data_sem);
+		return ret;
+	}
 
+	up_read(&EXT4_I(inode)->i_data_sem);
 	copied = block_write_end(pos, len, copied, folio);
 	/*
 	 * it's important to update i_size while still holding folio lock:
-- 
2.43.0

Forwarded: [PATCH] ext4: fix race in ext4_write_inline_data_end() by making it defensive

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: [PATCH] ext4: fix race in ext4_write_inline_data_end() by making it defensive
Author: kartikey406@gmail.com

#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-kernelci


Replace BUG_ON(!ext4_has_inline_data(inode)) with a defensive check in
ext4_write_inline_data_end(). This handles the race condition where a file
can be converted from inline to block storage by concurrent paths while a
write completion is in flight.

Multiple inline-to-block conversion paths exist and use different locking
mechanisms (ext4_convert_inline_data_nolock uses i_data_sem, while
ext4_convert_inline_data_to_extent and ext4_da_convert_inline_data_to_extent
use xattr_sem). A write that began on an inline file can reach completion
after the file has been converted to blocks by one of these paths.

Instead of crashing with BUG_ON, gracefully fall back to block_write_end()
when the file has already been converted. The data is already in blocks at
this point, so the fallback is correct.

Reported-by: syzbot+293a57918b36cfae3d48@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?extid=293a57918b36cfae3d48
Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>
---
 fs/ext4/inline.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/fs/ext4/inline.c b/fs/ext4/inline.c
index 8045e4ff270c..0a5404fe5bc5 100644
--- a/fs/ext4/inline.c
+++ b/fs/ext4/inline.c
@@ -812,7 +812,10 @@ int ext4_write_inline_data_end(struct inode *inode, loff_t pos, unsigned len,
 			goto out;
 		}
 		ext4_write_lock_xattr(inode, &no_expand);
-		BUG_ON(!ext4_has_inline_data(inode));
+		/* File may have been converted to block storage by concurrent path */
+		if (!ext4_has_inline_data(inode)) {
+			return block_write_end(pos, len, copied, folio);
+		}
 
 		/*
 		 * ei->i_inline_off may have changed since
-- 
2.43.0

Forwarded: [PATCH] ext4: make ext4_write_inline_data_end() handle file conversion gracefully

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: [PATCH] ext4: make ext4_write_inline_data_end() handle file conversion gracefully
Author: kartikey406@gmail.com

#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-kernelci


Replace BUG_ON(!ext4_has_inline_data(inode)) with a defensive check in
ext4_write_inline_data_end(). A file can be converted from inline to block
storage by concurrent paths while a write completion is in flight.

When this race occurs, the write completion handler should gracefully fall
back to block_write_end() instead of crashing. The data in the folio can
still be written to block storage via the fallback path.

This handles all inline-to-block conversion races regardless of which lock
protects the conversion (i_data_sem, xattr_sem, etc.).

Reported-by: syzbot+293a57918b36cfae3d48@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?extid=293a57918b36cfae3d48
Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>
---
 fs/ext4/inline.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/fs/ext4/inline.c b/fs/ext4/inline.c
index 8045e4ff270c..04b9cd01fd7b 100644
--- a/fs/ext4/inline.c
+++ b/fs/ext4/inline.c
@@ -812,7 +812,11 @@ int ext4_write_inline_data_end(struct inode *inode, loff_t pos, unsigned len,
 			goto out;
 		}
 		ext4_write_lock_xattr(inode, &no_expand);
-		BUG_ON(!ext4_has_inline_data(inode));
+		/* File may have been converted to block storage by concurrent path */
+		if (!ext4_has_inline_data(inode)) {
+			ext4_write_unlock_xattr(inode, &no_expand);
+			return block_write_end(pos, len, copied, folio);
+		}
 
 		/*
 		 * ei->i_inline_off may have changed since
-- 
2.43.0

Forwarded: [PATCH] ext4: handle inline-to-block file conversion race with error return

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: [PATCH] ext4: handle inline-to-block file conversion race with error return
Author: kartikey406@gmail.com

#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-kernelci


Replace fatal BUG_ON(!ext4_has_inline_data(inode)) with a defensive check
that returns -EIO when a file has been converted from inline to block
storage during write completion.

A file can transition from inline to block storage via concurrent paths
(mmap, readahead, truncate) while a write completion is in flight. If this
occurs, the write is in an inconsistent state and should not silently
succeed. Returning -EIO signals the error to the caller, allowing proper
retry and preventing silent data corruption.

Reported-by: syzbot+293a57918b36cfae3d48@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?extid=293a57918b36cfae3d48
Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>
---
 fs/ext4/inline.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/fs/ext4/inline.c b/fs/ext4/inline.c
index 8045e4ff270c..887a153924af 100644
--- a/fs/ext4/inline.c
+++ b/fs/ext4/inline.c
@@ -812,7 +812,11 @@ int ext4_write_inline_data_end(struct inode *inode, loff_t pos, unsigned len,
 			goto out;
 		}
 		ext4_write_lock_xattr(inode, &no_expand);
-		BUG_ON(!ext4_has_inline_data(inode));
+		/* File may have been converted to block storage by concurrent path */
+		if (!ext4_has_inline_data(inode)) {
+			ext4_write_unlock_xattr(inode, &no_expand);
+			return -EIO;
+		}
 
 		/*
 		 * ei->i_inline_off may have changed since
-- 
2.43.0

Forwarded: [PATCH] ext4: handle inline-to-block file conversion race with error return

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: [PATCH] ext4: handle inline-to-block file conversion race with error return
Author: kartikey406@gmail.com

#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-kernelci


Replace fatal BUG_ON(!ext4_has_inline_data(inode)) with a defensive check
that returns -EIO when a file has been converted from inline to block
storage during write completion.

A file can transition from inline to block storage via concurrent paths
(mmap, readahead, truncate) while a write completion is in flight. If this
occurs, the write is in an inconsistent state and should not silently
succeed. Returning -EIO signals the error to the caller, allowing proper
retry and preventing silent data corruption.

Reported-by: syzbot+293a57918b36cfae3d48@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?extid=293a57918b36cfae3d48
Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>
---
 fs/ext4/inline.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/fs/ext4/inline.c b/fs/ext4/inline.c
index 8045e4ff270c..53d783235da9 100644
--- a/fs/ext4/inline.c
+++ b/fs/ext4/inline.c
@@ -812,7 +812,14 @@ int ext4_write_inline_data_end(struct inode *inode, loff_t pos, unsigned len,
 			goto out;
 		}
 		ext4_write_lock_xattr(inode, &no_expand);
-		BUG_ON(!ext4_has_inline_data(inode));
+		/* File may have been converted to block storage by concurrent path */
+		if (!ext4_has_inline_data(inode)) {
+			ext4_write_unlock_xattr(inode, &no_expand);
+			brelse(iloc.bh);
+			folio_unlock(folio);
+			folio_put(folio);
+			return -EIO;
+		}
 
 		/*
 		 * ei->i_inline_off may have changed since
-- 
2.43.0