* Forwarded: [PATCH] ext4: add debug logging for inline data flag in ext4_iget
2026-02-02 18:16 [syzbot] [ext4?] kernel BUG in ext4_write_inline_data (4) syzbot
@ 2026-02-03 5:17 ` syzbot
2026-02-03 6:41 ` syzbot
` (5 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: syzbot @ 2026-02-03 5:17 UTC (permalink / raw)
To: linux-kernel, syzkaller-bugs
For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.
***
Subject: [PATCH] ext4: add debug logging for inline data flag in ext4_iget
Author: kartikey406@gmail.com
#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
Add debug printk statements to track inline data flag status and inode
size during inode loading. This helps diagnose corruption issues where
the EXT4_INLINE_DATA_FL flag may be set inconsistently with the actual
inode size.
The debug output logs:
- Raw inode mode, flags, and size fields
- Whether INLINE_DATA flag is set
- Whether EXTENTS flag is set
This is useful for investigating crashes in ext4_write_inline_data()
where the BUG_ON(pos + len > EXT4_I(inode)->i_inline_size) triggers
due to corrupted filesystem images that have inline data flag set
but file size exceeding inline capacity.
Reported-by: syzbot+7de5fe447862fc37576f@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?extid=7de5fe447862fc37576f
Signed-off-by: Deepanshu Kartikey <Kartikey406@gmail.com>
---
fs/ext4/inode.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index 0c466ccbed69..ad6eff690edd 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -5211,6 +5211,22 @@ struct inode *__ext4_iget(struct super_block *sb, unsigned long ino,
goto bad_inode;
raw_inode = ext4_raw_inode(&iloc);
+ printk(KERN_WARNING "EXT4-fs DEBUG: inode=%lu i_mode=0x%x i_flags=0x%x i_size_lo=%u i_size_hi=%u\n",
+ ino,
+ le16_to_cpu(raw_inode->i_mode),
+ le32_to_cpu(raw_inode->i_flags),
+ le32_to_cpu(raw_inode->i_size_lo),
+ le32_to_cpu(raw_inode->i_size_high));
+ /* Check if inline flag is set in raw flags */
+ if (le32_to_cpu(raw_inode->i_flags) & EXT4_INLINE_DATA_FL) {
+ printk(KERN_WARNING "EXT4-fs DEBUG: inode=%lu has INLINE_DATA flag set!\n", ino);
+ }
+
+ /* Check if extents flag is set in raw flags */
+ if (le32_to_cpu(raw_inode->i_flags) & EXT4_EXTENTS_FL) {
+ printk(KERN_WARNING "EXT4-fs DEBUG: inode=%lu has EXTENTS flag set!\n", ino);
+ }
+
if ((flags & EXT4_IGET_HANDLE) &&
(raw_inode->i_links_count == 0) && (raw_inode->i_mode == 0)) {
ret = -ESTALE;
--
2.43.0
^ permalink raw reply related [flat|nested] 8+ messages in thread* Forwarded: [PATCH] ext4: add debug logging for inline data flag in ext4_iget
2026-02-02 18:16 [syzbot] [ext4?] kernel BUG in ext4_write_inline_data (4) syzbot
2026-02-03 5:17 ` Forwarded: [PATCH] ext4: add debug logging for inline data flag in ext4_iget syzbot
@ 2026-02-03 6:41 ` syzbot
2026-02-03 7:52 ` Forwarded: [PATCH] ext4: validate inline data flag is consistent with inode size syzbot
` (4 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: syzbot @ 2026-02-03 6:41 UTC (permalink / raw)
To: linux-kernel, syzkaller-bugs
For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.
***
Subject: [PATCH] ext4: add debug logging for inline data flag in ext4_iget
Author: kartikey406@gmail.com
#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
Add debug printk statements to track inline data flag status and inode
size during inode loading. This helps diagnose corruption issues where
the EXT4_INLINE_DATA_FL flag may be set inconsistently with the actual
inode size.
The debug output logs:
- Raw inode mode, flags, and size fields
- Whether INLINE_DATA flag is set
- Whether EXTENTS flag is set
This is useful for investigating crashes in ext4_write_inline_data()
where the BUG_ON(pos + len > EXT4_I(inode)->i_inline_size) triggers
due to corrupted filesystem images that have inline data flag set
but file size exceeding inline capacity.
Reported-by: syzbot+7de5fe447862fc37576f@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?extid=7de5fe447862fc37576f
Signed-off-by: Deepanshu Kartikey <Kartikey406@gmail.com>
---
fs/ext4/inode.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index 0c466ccbed69..ad6eff690edd 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -5211,6 +5211,22 @@ struct inode *__ext4_iget(struct super_block *sb, unsigned long ino,
goto bad_inode;
raw_inode = ext4_raw_inode(&iloc);
+ printk(KERN_WARNING "EXT4-fs DEBUG: inode=%lu i_mode=0x%x i_flags=0x%x i_size_lo=%u i_size_hi=%u\n",
+ ino,
+ le16_to_cpu(raw_inode->i_mode),
+ le32_to_cpu(raw_inode->i_flags),
+ le32_to_cpu(raw_inode->i_size_lo),
+ le32_to_cpu(raw_inode->i_size_high));
+ /* Check if inline flag is set in raw flags */
+ if (le32_to_cpu(raw_inode->i_flags) & EXT4_INLINE_DATA_FL) {
+ printk(KERN_WARNING "EXT4-fs DEBUG: inode=%lu has INLINE_DATA flag set!\n", ino);
+ }
+
+ /* Check if extents flag is set in raw flags */
+ if (le32_to_cpu(raw_inode->i_flags) & EXT4_EXTENTS_FL) {
+ printk(KERN_WARNING "EXT4-fs DEBUG: inode=%lu has EXTENTS flag set!\n", ino);
+ }
+
if ((flags & EXT4_IGET_HANDLE) &&
(raw_inode->i_links_count == 0) && (raw_inode->i_mode == 0)) {
ret = -ESTALE;
--
2.43.0
^ permalink raw reply related [flat|nested] 8+ messages in thread* Forwarded: [PATCH] ext4: validate inline data flag is consistent with inode size
2026-02-02 18:16 [syzbot] [ext4?] kernel BUG in ext4_write_inline_data (4) syzbot
2026-02-03 5:17 ` Forwarded: [PATCH] ext4: add debug logging for inline data flag in ext4_iget syzbot
2026-02-03 6:41 ` syzbot
@ 2026-02-03 7:52 ` syzbot
2026-02-03 14:30 ` syzbot
` (3 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: syzbot @ 2026-02-03 7:52 UTC (permalink / raw)
To: linux-kernel, syzkaller-bugs
For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.
***
Subject: [PATCH] ext4: validate inline data flag is consistent with inode size
Author: kartikey406@gmail.com
#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
Add validation in ext4_iget() to detect corrupted inodes that have
the EXT4_INLINE_DATA_FL flag set but have a file size that exceeds
the inline data capacity.
Inline data in ext4 is stored in the inode's i_block array (60 bytes)
and extended attribute space (typically up to 100 bytes), with a
practical maximum of around 156 bytes. However, corrupted or
maliciously crafted filesystem images can have inodes with the inline
data flag set but claiming much larger sizes.
This inconsistency can trigger a kernel BUG_ON() in
ext4_write_inline_data() when the filesystem attempts to write data
through the inline data path:
kernel BUG at fs/ext4/inline.c:240!
BUG_ON(pos + len > EXT4_I(inode)->i_inline_size);
The crash occurs because:
1. Mount loads a corrupted inode with inline flag + large size
2. File operations like truncate() fail to convert to extent-based storage
3. Write operations (e.g., via sendfile) attempt inline data write
4. BUG_ON fires when write size exceeds actual inline capacity
This fix adds a check in ext4_iget() using a conservative 512 byte
limit. Any inode with the inline data flag but size exceeding this
limit is rejected with -EFSCORRUPTED, preventing the crash and
failing gracefully at mount time rather than during file operations.
The 512 byte threshold provides safety margin above the realistic
maximum inline size while catching corruption cases like the reported
50MB file with inline flag set.
Reported-by: syzbot+7de5fe447862fc37576f@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?extid=7de5fe447862fc37576f
Signed-off-by: Deepanshu Kartikey <Kartikey406@gmail.com>
---
fs/ext4/inode.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index 0c466ccbed69..ed79a558b6fd 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -5310,6 +5310,16 @@ struct inode *__ext4_iget(struct super_block *sb, unsigned long ino,
ret = -EFSCORRUPTED;
goto bad_inode;
}
+ if (ext4_test_inode_flag(inode, EXT4_INODE_INLINE_DATA)) {
+ if (size > 512) {
+ ext4_error_inode(inode, function, line, 0,
+ "iget: inline data flag set but size %lld exceeds capacity",
+ size);
+ ret = -EFSCORRUPTED;
+ goto bad_inode;
+ }
+ }
+
inode->i_blocks = ext4_inode_blocks(raw_inode, ei);
ei->i_file_acl = le32_to_cpu(raw_inode->i_file_acl_lo);
if (ext4_has_feature_64bit(sb))
--
2.43.0
^ permalink raw reply related [flat|nested] 8+ messages in thread* Forwarded: [PATCH] ext4: validate inline data flag is consistent with inode size
2026-02-02 18:16 [syzbot] [ext4?] kernel BUG in ext4_write_inline_data (4) syzbot
` (2 preceding siblings ...)
2026-02-03 7:52 ` Forwarded: [PATCH] ext4: validate inline data flag is consistent with inode size syzbot
@ 2026-02-03 14:30 ` syzbot
2026-02-06 13:10 ` Forwarded: [PATCH] ext4: add debug logging for setattr size operations syzbot
` (2 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: syzbot @ 2026-02-03 14:30 UTC (permalink / raw)
To: linux-kernel, syzkaller-bugs
For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.
***
Subject: [PATCH] ext4: validate inline data flag is consistent with inode size
Author: kartikey406@gmail.com
#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
Add validation in ext4_iget() to detect corrupted inodes that have
the EXT4_INLINE_DATA_FL flag set but have a file size that exceeds
the inline data capacity.
Inline data in ext4 is stored in the inode's i_block array (60 bytes)
and extended attribute space (typically up to 100 bytes), with a
practical maximum of around 156 bytes. However, corrupted or
maliciously crafted filesystem images can have inodes with the inline
data flag set but claiming much larger sizes.
This inconsistency can trigger a kernel BUG_ON() in
ext4_write_inline_data() when the filesystem attempts to write data
through the inline data path:
kernel BUG at fs/ext4/inline.c:240!
BUG_ON(pos + len > EXT4_I(inode)->i_inline_size);
The crash occurs because:
1. Mount loads a corrupted inode with inline flag + large size
2. File operations like truncate() fail to convert to extent-based storage
3. Write operations (e.g., via sendfile) attempt inline data write
4. BUG_ON fires when write size exceeds actual inline capacity
This fix adds a check in ext4_iget() using a conservative 512 byte
limit. Any inode with the inline data flag but size exceeding this
limit is rejected with -EFSCORRUPTED, preventing the crash and
failing gracefully at mount time rather than during file operations.
The 512 byte threshold provides safety margin above the realistic
maximum inline size while catching corruption cases like the reported
50MB file with inline flag set.
Reported-by: syzbot+7de5fe447862fc37576f@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?extid=7de5fe447862fc37576f
Signed-off-by: Deepanshu Kartikey <Kartikey406@gmail.com>
---
fs/ext4/inode.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index 0c466ccbed69..ed79a558b6fd 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -5310,6 +5310,16 @@ struct inode *__ext4_iget(struct super_block *sb, unsigned long ino,
ret = -EFSCORRUPTED;
goto bad_inode;
}
+ if (ext4_test_inode_flag(inode, EXT4_INODE_INLINE_DATA)) {
+ if (size > 512) {
+ ext4_error_inode(inode, function, line, 0,
+ "iget: inline data flag set but size %lld exceeds capacity",
+ size);
+ ret = -EFSCORRUPTED;
+ goto bad_inode;
+ }
+ }
+
inode->i_blocks = ext4_inode_blocks(raw_inode, ei);
ei->i_file_acl = le32_to_cpu(raw_inode->i_file_acl_lo);
if (ext4_has_feature_64bit(sb))
--
2.43.0
^ permalink raw reply related [flat|nested] 8+ messages in thread* Forwarded: [PATCH] ext4: add debug logging for setattr size operations
2026-02-02 18:16 [syzbot] [ext4?] kernel BUG in ext4_write_inline_data (4) syzbot
` (3 preceding siblings ...)
2026-02-03 14:30 ` syzbot
@ 2026-02-06 13:10 ` syzbot
2026-02-07 0:39 ` Forwarded: [PATCH] ext4: convert inline data to extents when truncate exceeds inline size syzbot
2026-02-11 11:30 ` [syzbot] [ext4?] kernel BUG in ext4_write_inline_data (4) syzbot
6 siblings, 0 replies; 8+ messages in thread
From: syzbot @ 2026-02-06 13:10 UTC (permalink / raw)
To: linux-kernel, syzkaller-bugs
For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.
***
Subject: [PATCH] ext4: add debug logging for setattr size operations
Author: kartikey406@gmail.com
#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
Add debug printk to track when ext4_setattr() is called with ATTR_SIZE,
logging the inode number, old size, new size, and whether the inode has
inline data flag set.
This is a diagnostic patch to investigate the crash reported by syzbot
where a BUG_ON() fires in ext4_write_inline_data() due to inodes having
the inline data flag set but claiming sizes far exceeding inline capacity.
The hypothesis is that truncate() operations that grow file size are not
properly converting inline data to extent-based storage, leaving inodes
in an inconsistent state (inline flag set + large size).
This debug output will confirm whether:
1. ext4_setattr() is called during truncate operations
2. The inline data flag remains set when size grows beyond capacity
3. Conversion to extent-based storage is missing from the truncate path
Related-to: syzbot+7de5fe447862fc37576f@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?extid=7de5fe447862fc37576f
Signed-off-by: Deepanshu Kartikey <Kartikey406@gmail.com>
---
fs/ext4/inode.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index 0c466ccbed69..ccaef3eb5a46 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -5886,7 +5886,8 @@ int ext4_setattr(struct mnt_idmap *idmap, struct dentry *dentry,
loff_t oldsize = inode->i_size;
loff_t old_disksize;
int shrink = (attr->ia_size < inode->i_size);
-
+ printk(KERN_WARNING "EXT4-fs DEBUG setattr: inode=%lu old_size=%lld new_size=%lld has_inline=%d\n",
+ inode->i_ino,oldsize,attr->ia_size,ext4_has_inline_data(inode) ? 1 : 0);
if (!(ext4_test_inode_flag(inode, EXT4_INODE_EXTENTS))) {
struct ext4_sb_info *sbi = EXT4_SB(inode->i_sb);
--
2.43.0
^ permalink raw reply related [flat|nested] 8+ messages in thread* Forwarded: [PATCH] ext4: convert inline data to extents when truncate exceeds inline size
2026-02-02 18:16 [syzbot] [ext4?] kernel BUG in ext4_write_inline_data (4) syzbot
` (4 preceding siblings ...)
2026-02-06 13:10 ` Forwarded: [PATCH] ext4: add debug logging for setattr size operations syzbot
@ 2026-02-07 0:39 ` syzbot
2026-02-11 11:30 ` [syzbot] [ext4?] kernel BUG in ext4_write_inline_data (4) syzbot
6 siblings, 0 replies; 8+ messages in thread
From: syzbot @ 2026-02-07 0:39 UTC (permalink / raw)
To: linux-kernel, syzkaller-bugs
For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.
***
Subject: [PATCH] ext4: convert inline data to extents when truncate exceeds inline size
Author: kartikey406@gmail.com
#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
Add a check in ext4_setattr() to convert files from inline data storage
to extent-based storage when truncate() grows the file size beyond the
inline capacity. This prevents the filesystem from entering an
inconsistent state where the inline data flag is set but the file size
exceeds what can be stored inline.
Without this fix, the following sequence causes a kernel BUG_ON():
1. Mount filesystem with inode that has inline flag set and small size
2. truncate(file, 50MB) - grows size but inline flag remains set
3. sendfile() attempts to write data
4. ext4_write_inline_data() hits BUG_ON(write_size > inline_capacity)
The crash occurs because ext4_write_inline_data() expects inline storage
to accommodate the write, but the actual inline capacity (~60 bytes for
i_block + ~96 bytes for xattrs) is far smaller than the file size and
write request.
The fix checks if the new size from setattr exceeds the inode's actual
inline capacity (EXT4_I(inode)->i_inline_size) and converts the file to
extent-based storage before proceeding with the size change. A debug
message is logged when conversion occurs to aid in diagnosis.
This addresses the root cause by ensuring the inline data flag and file
size remain consistent during truncate operations.
Reported-by: syzbot+7de5fe447862fc37576f@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?extid=7de5fe447862fc37576f
Signed-off-by: Deepanshu Kartikey <Kartikey406@gmail.com>
---
fs/ext4/inode.c | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index 0c466ccbed69..a1eb6d15fc28 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -5901,6 +5901,23 @@ int ext4_setattr(struct mnt_idmap *idmap, struct dentry *dentry,
if (attr->ia_size == inode->i_size)
inc_ivers = false;
+ /*
+ * If file has inline data but new size exceeds inline capacity,
+ * convert to extent-based storage first to prevent inconsistent
+ * state (inline flag set but size exceeds inline capacity).
+ */
+ if (ext4_has_inline_data(inode) &&
+ attr->ia_size > EXT4_I(inode)->i_inline_size) {
+ printk(KERN_WARNING "EXT4-fs: Converting inline data: inode=%lu old_size=%lld new_size=%lld inline_size=%u\n",
+ inode->i_ino,
+ inode->i_size,
+ attr->ia_size,
+ EXT4_I(inode)->i_inline_size);
+ error = ext4_convert_inline_data(inode);
+ if (error)
+ goto err_out;
+ }
+
if (shrink) {
if (ext4_should_order_data(inode)) {
error = ext4_begin_ordered_truncate(inode,
--
2.43.0
^ permalink raw reply related [flat|nested] 8+ messages in thread* Re: [syzbot] [ext4?] kernel BUG in ext4_write_inline_data (4)
2026-02-02 18:16 [syzbot] [ext4?] kernel BUG in ext4_write_inline_data (4) syzbot
` (5 preceding siblings ...)
2026-02-07 0:39 ` Forwarded: [PATCH] ext4: convert inline data to extents when truncate exceeds inline size syzbot
@ 2026-02-11 11:30 ` syzbot
6 siblings, 0 replies; 8+ messages in thread
From: syzbot @ 2026-02-11 11:30 UTC (permalink / raw)
To: adilger.kernel, kartikey406, linux-ext4, linux-kernel,
syzkaller-bugs, tytso
syzbot has found a reproducer for the following issue on:
HEAD commit: dc855b77719f Merge tag 'irq-drivers-2026-02-09' of git://g..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=179e0b3a580000
kernel config: https://syzkaller.appspot.com/x/.config?x=c48edf5effbe2b83
dashboard link: https://syzkaller.appspot.com/bug?extid=7de5fe447862fc37576f
compiler: Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=137b6ae6580000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=109fb402580000
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/d7c9816606c2/disk-dc855b77.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/cb6f0c59d3d1/vmlinux-dc855b77.xz
kernel image: https://storage.googleapis.com/syzbot-assets/7abf33193f14/bzImage-dc855b77.xz
mounted in repro: https://storage.googleapis.com/syzbot-assets/cc23e4e0f61c/mount_0.gz
fsck result: failed (log: https://syzkaller.appspot.com/x/fsck.log?x=11aaccaa580000)
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+7de5fe447862fc37576f@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: 6183 Comm: syz.1.27 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/24/2026
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 3a 5d ac ff 4c 89 fa e9 06 ff ff ff e8 7d 31 43 ff 90 0f 0b e8 75 31 43 ff 90 <0f> 0b 66 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f
RSP: 0018:ffffc900041bf3a8 EFLAGS: 00010293
RAX: ffffffff8281434b RBX: 0000000000003000 RCX: ffff88802ab8dac0
RDX: 0000000000000000 RSI: 000000000000003c RDI: 0000000000003000
RBP: ffff888072ee11a2 R08: ffff88805b996387 R09: 1ffff1100b732c70
R10: dffffc0000000000 R11: ffffed100b732c71 R12: 000000000000003c
R13: ffffc900041bf460 R14: 0000000000002000 R15: ffff888072ee0c38
FS: 00007f67e2ffe6c0(0000) GS:ffff8881256ca000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00005555753c59e8 CR3: 0000000079001000 CR4: 0000000000350ef0
Call Trace:
<TASK>
ext4_write_inline_data_end+0x34d/0xad0 fs/ext4/inline.c:817
generic_perform_write+0x620/0x8f0 mm/filemap.c:4335
ext4_buffered_write_iter+0xce/0x3a0 fs/ext4/file.c:300
ext4_file_write_iter+0x298/0x1c10 fs/ext4/file.c:-1
iter_file_splice_write+0x99b/0x1100 fs/splice.c:738
do_splice_from fs/splice.c:938 [inline]
direct_splice_actor+0x101/0x160 fs/splice.c:1161
splice_direct_to_actor+0x53a/0xc70 fs/splice.c:1105
do_splice_direct_actor fs/splice.c:1204 [inline]
do_splice_direct+0x195/0x290 fs/splice.c:1230
do_sendfile+0x535/0x7d0 fs/read_write.c:1372
__do_sys_sendfile64 fs/read_write.c:1433 [inline]
__se_sys_sendfile64+0x144/0x1a0 fs/read_write.c:1419
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f67e399bf79
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 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 e8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f67e2ffe028 EFLAGS: 00000246 ORIG_RAX: 0000000000000028
RAX: ffffffffffffffda RBX: 00007f67e3c15fa0 RCX: 00007f67e399bf79
RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000004
RBP: 00007f67e3a327e0 R08: 0000000000000000 R09: 0000000000000000
R10: 000000000e3aa6ea R11: 0000000000000246 R12: 0000000000000000
R13: 00007f67e3c16038 R14: 00007f67e3c15fa0 R15: 00007fff789394f8
</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 3a 5d ac ff 4c 89 fa e9 06 ff ff ff e8 7d 31 43 ff 90 0f 0b e8 75 31 43 ff 90 <0f> 0b 66 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f
RSP: 0018:ffffc900041bf3a8 EFLAGS: 00010293
RAX: ffffffff8281434b RBX: 0000000000003000 RCX: ffff88802ab8dac0
RDX: 0000000000000000 RSI: 000000000000003c RDI: 0000000000003000
RBP: ffff888072ee11a2 R08: ffff88805b996387 R09: 1ffff1100b732c70
R10: dffffc0000000000 R11: ffffed100b732c71 R12: 000000000000003c
R13: ffffc900041bf460 R14: 0000000000002000 R15: ffff888072ee0c38
FS: 00007f67e2ffe6c0(0000) GS:ffff8881256ca000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fa159255000 CR3: 0000000079001000 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.
^ permalink raw reply [flat|nested] 8+ messages in thread