From: syzbot <syzbot+f3185be57d7e8dda32b8@syzkaller.appspotmail.com>
To: linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com
Subject: Forwarded: [PATCH] ext4: fix inline data overflow when xattr value is empty
Date: Sat, 18 Oct 2025 08:11:56 -0700 [thread overview]
Message-ID: <68f3ae3c.050a0220.91a22.0432.GAE@google.com> (raw)
In-Reply-To: <68c58bfa.050a0220.3c6139.04d2.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 inline data overflow when xattr value is empty
Author: kartikey406@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+f3185be57d7e8dda32b8@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=f3185be57d7e8dda32b8
Signed-off-by: Deepanshu Kartikey <kartikey406@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
next prev parent reply other threads:[~2025-10-18 15:11 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-13 15:21 [syzbot] [ext4?] kernel BUG in ext4_write_inline_data (3) syzbot
2025-10-03 1:55 ` syzbot
2025-10-07 22:19 ` Forwarded: kernel BUG in ext4_write_inline_data syzbot
2025-10-09 1:34 ` Forwarded: kernel BUG in ext4_write_inline_data (3) syzbot
2025-10-18 15:11 ` syzbot [this message]
2025-10-20 5:07 ` Forwarded: [PATCH v2] ext4: refresh inline data size before write operations syzbot
2025-11-10 21:36 ` Forwarded: Re: kernel BUG in ext4_write_inline_data (3) syzbot
2025-11-11 1:12 ` syzbot
2025-11-11 4:50 ` syzbot
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=68f3ae3c.050a0220.91a22.0432.GAE@google.com \
--to=syzbot+f3185be57d7e8dda32b8@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