From nobody Sat Feb 7 22:55:17 2026 Received: from mail-oa1-f72.google.com (mail-oa1-f72.google.com [209.85.160.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 90BF623BD1A for ; Tue, 3 Feb 2026 07:52:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.72 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770105167; cv=none; b=jisiyHrhPWCEB3iEX1bYnDeVEVXYG/0/Hp2Hw6Py1vvT6uoxCSbyChfppav/MmjFwkjfSQFRzZgdWqY+z90g8quitL/cTMic1/4Ixt43hfTqsd9YdDO6SAxOuVmVtnuXqFeXIH9emnhdf62nbbgN8Al2Om4FC5dGujpXVSbzc2M= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770105167; c=relaxed/simple; bh=liT6FG1tsU7LKKIkGzqlC1qCSsqbL5TsmBpzZfVRzCY=; h=MIME-Version:Date:In-Reply-To:Message-ID:Subject:From:To: Content-Type; b=J6L8RuNTGtlgatqnyIEw9XS0lJNgOWgUMV6bfPGblH8vCfAEOWXZINHIExv/kUqebiHf4LvD5o9Gue73VWSbCCeXoEK+qflwjZcDqSsPU8icGm76T4Fl8/L4jsgy6ihRmhBjUVdnX85A33OWXoZWGd+W8Liebfcj4IMh1Y/V8R4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=fail (p=none dis=none) header.from=syzkaller.appspotmail.com; spf=pass smtp.mailfrom=M3KW2WVRGUFZ5GODRSRYTGD7.apphosting.bounces.google.com; arc=none smtp.client-ip=209.85.160.72 Authentication-Results: smtp.subspace.kernel.org; dmarc=fail (p=none dis=none) header.from=syzkaller.appspotmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=M3KW2WVRGUFZ5GODRSRYTGD7.apphosting.bounces.google.com Received: by mail-oa1-f72.google.com with SMTP id 586e51a60fabf-4081db82088so12526209fac.1 for ; Mon, 02 Feb 2026 23:52:45 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770105164; x=1770709964; h=to:from:subject:message-id:in-reply-to:date:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=ZpgvA1Krn36JujWxx8xrOf8ZSL3oPZDodaDHrpqzqMI=; b=Eo/5ymhVqBJE28udADctxkik5hivz+W611GNce5fwHp32Kk46RknIEfObOWgRE/Ajg C5xEV5HU5gT1SKCYzaHOwhz+F8cZZtok2pnuiF62GvVHmTsEKVkKWQo9ymLvg8t58KjB 0HvljVsg3ldHBDEh9aqm1VTdJETbP55bgcRJN7k54vbYxXQIKhePsRteEiRRjCLdUEKh oEmT55VRNTDFZE1icZZOkYfV8udPQfB9UI3z+/wHbp4s+3w15Oz+D+RCuDdPwPgzg5pJ ENLy8i7rv7xGB+0f0MVEC4+x44L7italHY6daGt7IA2CzvPvW7GOkigsdK/dvShukAUb utFg== X-Gm-Message-State: AOJu0YxhDN3Zvb92aPA+s7WS5ZbTaOuptUMFMg5L7GC9u3l/2fGMr8fc 3xCTJ/nzTWlitDb//BYS8ydukCjzG5pGmawXv88PArSdo00Td3s0JbNtkInG+PHg0gx4aFhqvhk i6AhrB/XcqSVngVgZnDLN1fNk6Z3W8DrGEf2zqbRniP2+ICUdC4oJ5+OHjNo= Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Received: by 2002:a05:6820:98f:b0:663:40d:4897 with SMTP id 006d021491bc7-6630f3a457bmr6660195eaf.70.1770105164547; Mon, 02 Feb 2026 23:52:44 -0800 (PST) Date: Mon, 02 Feb 2026 23:52:44 -0800 In-Reply-To: <6980e9ff.050a0220.16b13.00a9.GAE@google.com> X-Google-Appengine-App-Id: s~syzkaller X-Google-Appengine-App-Id-Alias: syzkaller Message-ID: <6981a94c.050a0220.3b3015.0008.GAE@google.com> Subject: Forwarded: [PATCH] ext4: validate inline data flag is consistent with inode size From: syzbot To: linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" 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 s= ize 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=3D7de5fe447862fc37576f Signed-off-by: Deepanshu Kartikey --- 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, un= signed long ino, ret =3D -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 =3D -EFSCORRUPTED; + goto bad_inode; + } + } + inode->i_blocks =3D ext4_inode_blocks(raw_inode, ei); ei->i_file_acl =3D le32_to_cpu(raw_inode->i_file_acl_lo); if (ext4_has_feature_64bit(sb)) --=20 2.43.0