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

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit: 5f540c4aade9 Add linux-next specific files for 20250910
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=10025d62580000
kernel config: https://syzkaller.appspot.com/x/.config?x=5ed48faa2cb8510d
dashboard link: https://syzkaller.appspot.com/bug?extid=f3185be57d7e8dda32b8
compiler: Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8

Unfortunately, I don't have any reproducer for this issue yet.

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/df0dfb072f52/disk-5f540c4a.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/20649042ae30/vmlinux-5f540c4a.xz
kernel image: https://storage.googleapis.com/syzbot-assets/4c16358268b8/bzImage-5f540c4a.xz

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

------------[ cut here ]------------
kernel BUG at fs/ext4/inline.c:240!
Oops: invalid opcode: 0000 [#1] SMP KASAN PTI
CPU: 0 UID: 0 PID: 28152 Comm: syz.8.5004 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025
RIP: 0010:ext4_write_inline_data+0x43c/0x440 fs/ext4/inline.c:240
Code: c1 38 c1 0f 8c 19 ff ff ff 48 89 df 49 89 d7 e8 fa c8 b0 ff 4c 89 fa e9 06 ff ff ff e8 7d c2 4c ff 90 0f 0b e8 75 c2 4c ff 90 <0f> 0b 66 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 0f
RSP: 0018:ffffc900045273a8 EFLAGS: 00010287
RAX: ffffffff8272facb RBX: 0000000000003000 RCX: 0000000000080000
RDX: ffffc90016e08000 RSI: 0000000000001d1a RDI: 0000000000001d1b
RBP: ffff888012035472 R08: ffff88807cd4e387 R09: 1ffff1100f9a9c70
R10: dffffc0000000000 R11: ffffed100f9a9c71 R12: 000000000000003c
R13: ffffc90004527460 R14: 0000000000002000 R15: ffff888012034f18
FS: 00007f73a18866c0(0000) GS:ffff8881259f0000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000001b30511ff8 CR3: 0000000049be6000 CR4: 00000000003526f0
Call Trace:
<TASK>
ext4_write_inline_data_end+0x336/0xab0 fs/ext4/inline.c:807
generic_perform_write+0x627/0x900 mm/filemap.c:4230
ext4_buffered_write_iter+0xce/0x3a0 fs/ext4/file.c:299
ext4_file_write_iter+0x298/0x1bc0 fs/ext4/file.c:-1
iter_file_splice_write+0x972/0x10e0 fs/splice.c:738
do_splice_from fs/splice.c:938 [inline]
direct_splice_actor+0xfe/0x160 fs/splice.c:1161
splice_direct_to_actor+0x5a8/0xcc0 fs/splice.c:1105
do_splice_direct_actor fs/splice.c:1204 [inline]
do_splice_direct+0x181/0x270 fs/splice.c:1230
do_sendfile+0x4da/0x7e0 fs/read_write.c:1370
__do_sys_sendfile64 fs/read_write.c:1431 [inline]
__se_sys_sendfile64+0x13e/0x190 fs/read_write.c:1417
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xfa/0xfa0 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f73a098eba9
Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f73a1886038 EFLAGS: 00000246 ORIG_RAX: 0000000000000028
RAX: ffffffffffffffda RBX: 00007f73a0bd5fa0 RCX: 00007f73a098eba9
RDX: 0000000000000000 RSI: 0000000000000006 RDI: 0000000000000004
RBP: 00007f73a0a11e19 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000020fffe82 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f73a0bd6038 R14: 00007f73a0bd5fa0 R15: 00007ffcafa37c38
</TASK>
Modules linked in:
---[ end trace 0000000000000000 ]---
RIP: 0010:ext4_write_inline_data+0x43c/0x440 fs/ext4/inline.c:240
Code: c1 38 c1 0f 8c 19 ff ff ff 48 89 df 49 89 d7 e8 fa c8 b0 ff 4c 89 fa e9 06 ff ff ff e8 7d c2 4c ff 90 0f 0b e8 75 c2 4c ff 90 <0f> 0b 66 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 0f
RSP: 0018:ffffc900045273a8 EFLAGS: 00010287
RAX: ffffffff8272facb RBX: 0000000000003000 RCX: 0000000000080000
RDX: ffffc90016e08000 RSI: 0000000000001d1a RDI: 0000000000001d1b
RBP: ffff888012035472 R08: ffff88807cd4e387 R09: 1ffff1100f9a9c70
R10: dffffc0000000000 R11: ffffed100f9a9c71 R12: 000000000000003c
R13: ffffc90004527460 R14: 0000000000002000 R15: ffff888012034f18
FS: 00007f73a18866c0(0000) GS:ffff8881259f0000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f8fb8e97d58 CR3: 0000000049be6000 CR4: 00000000003526f0


---
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 syzk...@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 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

[syzbot]

syzbot has found a reproducer for the following issue on:

HEAD commit: 7f7072574127 Merge tag 'kbuild-6.18-1' of git://git.kernel..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=135c1ee2580000
kernel config: https://syzkaller.appspot.com/x/.config?x=f9d13d0fd373120a

dashboard link: https://syzkaller.appspot.com/bug?extid=f3185be57d7e8dda32b8
compiler: Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8

syz repro: https://syzkaller.appspot.com/x/repro.syz?x=17e49334580000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=16758458580000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/0dce8562bc0e/disk-7f707257.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/f79b72b8bfa8/vmlinux-7f707257.xz
kernel image: https://storage.googleapis.com/syzbot-assets/a0289c1875c1/bzImage-7f707257.xz
mounted in repro: https://storage.googleapis.com/syzbot-assets/3bb52035efeb/mount_0.gz
fsck result: failed (log: https://syzkaller.appspot.com/x/fsck.log?x=1022a85b980000)

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

------------[ cut here ]------------
kernel BUG at fs/ext4/inline.c:240!

Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI
CPU: 0 UID: 0 PID: 7460 Comm: syz.5.349 Not tainted syzkaller #0 PREEMPT(full)

Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025
RIP: 0010:ext4_write_inline_data+0x43c/0x440 fs/ext4/inline.c:240

Code: c1 38 c1 0f 8c 19 ff ff ff 48 89 df 49 89 d7 e8 fa b0 b0 ff 4c 89 fa e9 06 ff ff ff e8 2d 07 4c ff 90 0f 0b e8 25 07 4c ff 90 <0f> 0b 66 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 0f
RSP: 0018:ffffc9000bff7828 EFLAGS: 00010293
RAX: ffffffff82726f5b RBX: 0000000000000078 RCX: ffff888026215ac0
RDX: 0000000000000000 RSI: 000000000000003c RDI: 0000000000000078
RBP: ffff8880773424a2 R08: ffff8880599a2387 R09: 1ffff1100b334470
R10: dffffc0000000000 R11: ffffed100b334471 R12: 000000000000003c
R13: ffffc9000bff78e0 R14: 0000000000000000 R15: ffff888077341f48
FS: 00007f61146ab6c0(0000) GS:ffff888126380000(0000) knlGS:0000000000000000

CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033

CR2: 00007fdcd7e1e000 CR3: 0000000010f34000 CR4: 0000000000350ef0

Call Trace:
<TASK>
ext4_write_inline_data_end+0x336/0xab0 fs/ext4/inline.c:807

generic_perform_write+0x62a/0x900 mm/filemap.c:4196

ext4_buffered_write_iter+0xce/0x3a0 fs/ext4/file.c:299
ext4_file_write_iter+0x298/0x1bc0 fs/ext4/file.c:-1

new_sync_write fs/read_write.c:593 [inline]
vfs_write+0x5c9/0xb30 fs/read_write.c:686
ksys_write+0x145/0x250 fs/read_write.c:738
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f611378eec9

Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48

RSP: 002b:00007f61146ab038 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 00007f61139e5fa0 RCX: 00007f611378eec9
RDX: 0000000000000078 RSI: 0000200000000600 RDI: 0000000000000005
RBP: 00007f6113811f91 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f61139e6038 R14: 00007f61139e5fa0 R15: 00007fff25d44648

</TASK>
Modules linked in:
---[ end trace 0000000000000000 ]---
RIP: 0010:ext4_write_inline_data+0x43c/0x440 fs/ext4/inline.c:240

Code: c1 38 c1 0f 8c 19 ff ff ff 48 89 df 49 89 d7 e8 fa b0 b0 ff 4c 89 fa e9 06 ff ff ff e8 2d 07 4c ff 90 0f 0b e8 25 07 4c ff 90 <0f> 0b 66 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 0f
RSP: 0018:ffffc9000bff7828 EFLAGS: 00010293
RAX: ffffffff82726f5b RBX: 0000000000000078 RCX: ffff888026215ac0
RDX: 0000000000000000 RSI: 000000000000003c RDI: 0000000000000078
RBP: ffff8880773424a2 R08: ffff8880599a2387 R09: 1ffff1100b334470
R10: dffffc0000000000 R11: ffffed100b334471 R12: 000000000000003c
R13: ffffc9000bff78e0 R14: 0000000000000000 R15: ffff888077341f48
FS: 00007f61146ab6c0(0000) GS:ffff888126380000(0000) knlGS:0000000000000000

CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033

CR2: 00007efcc67a1d58 CR3: 0000000010f34000 CR4: 0000000000350ef0


---
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.

[syzbot]

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

***

Subject: [PATCH] ext4: fix inline data overflow when xattr value is empty
Author: karti...@gmail.com

#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master

When a file has inline data with an xattr entry but e_value_size is 0,
ext4_prepare_inline_data() incorrectly uses the theoretical maximum
inline size (128 bytes) instead of the actual current capacity (60 bytes
from i_block only). This causes it to accept writes that exceed the
actual capacity, leading to a kernel crash in ext4_write_inline_data_end()
when the BUG_ON(pos + len > EXT4_I(inode)->i_inline_size) is triggered.

This scenario occurs when:
1. A file is created with inline data
2. The file is truncated, leaving an xattr entry with e_value_size=0
3. A write is attempted that exceeds i_block capacity (>60 bytes)

The bug occurs because ext4_prepare_inline_data() calls
ext4_get_max_inline_size() which returns the theoretical maximum (128)
even when the xattr value space is not allocated. This leads to:
- ext4_prepare_inline_data() thinks the write will fit (120 < 128)
- Does not return -ENOSPC
- Inline write path is taken
- ext4_write_inline_data_end() detects overflow and crashes

The fix checks e_value_size in ext4_prepare_inline_data():
- If e_value_size is 0: xattr exists but has no data, cannot expand,
use actual current capacity (i_inline_size)
- If e_value_size > 0: xattr has data, expansion possible,
use theoretical maximum (ext4_get_max_inline_size)
- If no xattr entry: use theoretical maximum

This ensures the capacity check accurately reflects available space,
triggering proper conversion to extents when needed and preventing
the overflow crash.

Reported-by: syzbot+f3185b...@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=f3185be57d7e8dda32b8
Signed-off-by: Deepanshu Kartikey <karti...@gmail.com>
---
fs/ext4/inline.c | 25 ++++++++++++++++++++++++-
1 file changed, 24 insertions(+), 1 deletion(-)

diff --git a/fs/ext4/inline.c b/fs/ext4/inline.c
index 1b094a4f3866..3a3aa2d803db 100644
--- a/fs/ext4/inline.c
+++ b/fs/ext4/inline.c
@@ -413,7 +413,30 @@ static int ext4_prepare_inline_data(handle_t *handle, struct inode *inode,
if (!ext4_test_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA))
return -ENOSPC;

- size = ext4_get_max_inline_size(inode);
+ if (ei->i_inline_off) {
+ struct ext4_iloc iloc;
+ struct ext4_inode *raw_inode;
+ struct ext4_xattr_entry *entry;
+
+ ret = ext4_get_inode_loc(inode, &iloc);
+ if (ret)
+ return ret;
+
+ raw_inode = ext4_raw_inode(&iloc);
+ entry = (struct ext4_xattr_entry *)
+ ((void *)raw_inode + ei->i_inline_off);
+
+ if (le32_to_cpu(entry->e_value_size) == 0) {
+ ext4_find_inline_data_nolock(inode);
+ size = ei->i_inline_size;
+ } else {
+ size = ext4_get_max_inline_size(inode);
+ }
+
+ brelse(iloc.bh);
+ } else {
+ size = ext4_get_max_inline_size(inode);
+ }
if (size < len)
return -ENOSPC;

--
2.43.0

[syzbot]

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

***

Subject: [PATCH v2] ext4: refresh inline data size before write operations

Author: karti...@gmail.com

#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master

The cached ei->i_inline_size can become stale between the initial size
check and when ext4_update_inline_data()/ext4_create_inline_data() use
it. Although ext4_get_max_inline_size() reads the correct value at the
time of the check, concurrent xattr operations can modify i_inline_size
before ext4_write_lock_xattr() is acquired.

This causes ext4_update_inline_data() and ext4_create_inline_data() to
work with stale capacity values, leading to a BUG_ON() crash in
ext4_write_inline_data():

kernel BUG at fs/ext4/inline.c:1331!
BUG_ON(pos + len > EXT4_I(inode)->i_inline_size);

The race window:
1. ext4_get_max_inline_size() reads i_inline_size = 60 (correct)
2. Size check passes for 50-byte write
3. [Another thread adds xattr, i_inline_size changes to 40]
4. ext4_write_lock_xattr() acquires lock
5. ext4_update_inline_data() uses stale i_inline_size = 60
6. Attempts to write 50 bytes but only 40 bytes actually available
7. BUG_ON() triggers

Fix this by recalculating i_inline_size via ext4_find_inline_data_nolock()
immediately after acquiring xattr_sem. This ensures ext4_update_inline_data()
and ext4_create_inline_data() work with current values that are protected
from concurrent modifications.

This is similar to commit a54c4613dac1 ("ext4: fix race writing to an
inline_data file while its xattrs are changing") which fixed i_inline_off
staleness. This patch addresses the related i_inline_size staleness issue.

Reported-by: syzbot+f3185b...@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?extid=f3185be57d7e8dda32b8
Cc: sta...@kernel.org

Signed-off-by: Deepanshu Kartikey <karti...@gmail.com>
---

Changes in v2:
- Simplified to single-line fix (refresh i_inline_size after taking lock)
- The refresh protects ext4_update_inline_data()/ext4_create_inline_data()
from using stale i_inline_size that may have changed between the initial
size check and lock acquisition
- Follows same pattern as commit a54c4613dac1 for consistency
---
fs/ext4/inline.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/fs/ext4/inline.c b/fs/ext4/inline.c
index 1b094a4f3866..b48c7dbe76a2 100644
--- a/fs/ext4/inline.c
+++ b/fs/ext4/inline.c
@@ -418,7 +418,12 @@ static int ext4_prepare_inline_data(handle_t *handle, struct inode *inode,
return -ENOSPC;

ext4_write_lock_xattr(inode, &no_expand);
-
+ /*
+ * ei->i_inline_size may have changed since the initial check
+ * if other xattrs were added. Recalculate to ensure
+ * ext4_update_inline_data() validates against current capacity.
+ */
+ (void) ext4_find_inline_data_nolock(inode);
if (ei->i_inline_off)
ret = ext4_update_inline_data(handle, inode, len);
else
--
2.43.0