From nobody Sun Feb 8 02:41:39 2026 Received: from mail-pj1-f45.google.com (mail-pj1-f45.google.com [209.85.216.45]) (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 7ED3F2D7392 for ; Sat, 7 Feb 2026 04:36:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.45 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770438975; cv=none; b=UYEcWIKelztajO1GMvuNNIQ31DwI5qt5N1cc67fsL7OreI1U1ggFLBO8Q+v378gECzljSFHF5p+fKtBnYpflpbFSM9TygiG3u5Fab//DZ/yGcDrOMitVvIUz/nZtTlYMjGBGYP3mmlmoQRBZUS0CxgfZjKpGY4wYnMUC/vsGy0c= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770438975; c=relaxed/simple; bh=LOu565aMnPMalQFcSP7BM4GVOKkia4TKLD4EhGhjiTc=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=c5cNY/8Iz7yk4X2zj8RP7jMItrUGBuQS77A8oq9Rg1nKPysm2oXn0a+z+/5rOqX/tJGrCRN23fLrTuCm7TKHca08sCNwJbZ7vEoIe9PohXJ0atf3F6+Mc0pL8V5AMyLOwsS2PLNeaR+dWW13Xm6kbYxwiV5uk0QBWc39hk0jOiM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=RdD91u52; arc=none smtp.client-ip=209.85.216.45 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="RdD91u52" Received: by mail-pj1-f45.google.com with SMTP id 98e67ed59e1d1-3540266d356so1893365a91.0 for ; Fri, 06 Feb 2026 20:36:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1770438975; x=1771043775; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=u6l+ANQIq478T27+r1YavztrZap8Og8nO5Z+UVtAbxQ=; b=RdD91u52+o7laG2vt5S7yErCUvgqEW17oS2gjhdVjgUZms7YRVod3kJ91Lruj3a9xR LJmelpPhLgC7fjvQr8XDYjS9EDl+uM26+95mTqOfw2ouzgSQ/gX4R0zrhiXcRVe2b3KN CHrScDT9CEw+IwuByYK47W/YbSbdJ9i3VZlBuxzw/sVMbwyRuS+BvlfTiLSgoP7DL7f/ 31AzXnRoIj8/6GEv3qTl5KAI5K+13iG27o4G1EHdhbUTydOKevmdrHv6WWq0YYq25uLR SpkcBfP7N4Wj1P0rvXIFv7ZIxPy/vayV6L7VYQh7u3JRqcnTVD+LIcw94jnfoUxXOCLS w2fw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770438975; x=1771043775; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=u6l+ANQIq478T27+r1YavztrZap8Og8nO5Z+UVtAbxQ=; b=whX/JeaUyQbAa1p/A/L/XmYIxa39GbFvIGI0yct3K8V4+7vmGomtBUCTRSdsMINSBV A8+NqbSzab9lpWiuGIdoA10NodeLY3JBrXCB9rFnHLnvxlglmocIWO4MnIBl9C9R3+FM 7dWjailTbviipRiI2VwU7lp4Zrn8A5jHEqwB0E20f/zuNr+jTlf7ETrzI8UONqcOqTSB ryVQZSJO/zTRzH+vpB+tR3x+776cJ2nsy9eVLmR1Olg71VSG+Jvo8ZNuqYH3ArdqOe6G l/4GijLDtVeK9W/0Be5dS9zWqkxK0wiLB0TqIcDkDvIIoNmhVsY2i47wp4WG4aK81Pqj HSUA== X-Forwarded-Encrypted: i=1; AJvYcCXSsnQhQIWcY3sQHscyeopm+EEMMzXnmZ0tIxHHD35mucdUGGl92+kRuyA8wNhu2frBExllD6dNp44wUkM=@vger.kernel.org X-Gm-Message-State: AOJu0Ywe1YWiEguJLnc5z6xIR3LIk3gKUAyloFrgPDjZniGZ/Sv7o8n/ h5PcS3XXiKDDj6qLaPV23EuuxYbaNBFC7iFiTq9TCVB7SVJ6YsWhumWB X-Gm-Gg: AZuq6aJgBzlDgGJ88va3SRWBS0uRztFH38nKtE+1s13hZsDjy+99MdsaULTUcdUtXW9 SCGmcrkkdADcWQUx6Y6PW4eOtlcczZ8AIUbRGqRxXB0FoWgm5jJkr27shgaZvzAqb+DuOdc6BhC 3wRCb+JnJiqa4oexYff7BZopOzf8Cxq+9Kc+T1+1qowUuDQn4FFjYbfPaY3wVey3fOjWgKwBa2O xQJbTsdDqsXSJ6clXJQtcjDUd2jGVNLjExCKJJoz5+eAJPY4Jmm0gJatKr2wXq5SXc+0E49oEcJ 3Xr/rFtjBZoUYdcLb+9KLfFusIyc0LZNxuPEBeAb8luLpoQhQ7rQ1nyIMTdeB/4p2hn8JUteudf NqfTfLItlNe25xYDDeP3KvyFRuCOowueRKdwqFdFwEb53SvbGH6yudyYsNQexzPJRRhNJ+jLqWs H/pYejY7At51JBOMVJ1Wvti0N4qD0nkaMfiJKFsASOumvGpD4nteQZYUgE8I9Rtet85w0= X-Received: by 2002:a17:90b:5348:b0:34a:b4a2:f0c8 with SMTP id 98e67ed59e1d1-354b3e5c2f9mr3893129a91.30.1770438974808; Fri, 06 Feb 2026 20:36:14 -0800 (PST) Received: from deepanshu-kernel-hacker.. ([2405:201:682f:389d:7e49:7e31:b8c9:621a]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-354c02a7ad6sm1011537a91.2.2026.02.06.20.36.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 06 Feb 2026 20:36:14 -0800 (PST) From: Deepanshu Kartikey To: tytso@mit.edu, adilger.kernel@dilger.ca Cc: linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org, Deepanshu Kartikey , syzbot+7de5fe447862fc37576f@syzkaller.appspotmail.com, Deepanshu Kartikey Subject: [PATCH] ext4: convert inline data to extents when truncate exceeds inline size Date: Sat, 7 Feb 2026 10:06:07 +0530 Message-ID: <20260207043607.1175976-1-kartikey406@gmail.com> X-Mailer: git-send-email 2.43.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" 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. 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 Closes: https://syzkaller.appspot.com/bug?extid=3D7de5fe447862fc37576f Tested-by: syzbot+7de5fe447862fc37576f@syzkaller.appspotmail.com Signed-off-by: Deepanshu Kartikey --- fs/ext4/inode.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c index 0c466ccbed69..c3dc0422ff95 100644 --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c @@ -5901,6 +5901,18 @@ int ext4_setattr(struct mnt_idmap *idmap, struct den= try *dentry, if (attr->ia_size =3D=3D inode->i_size) inc_ivers =3D false; =20 + /* + * 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) { + error =3D ext4_convert_inline_data(inode); + if (error) + goto err_out; + } + if (shrink) { if (ext4_should_order_data(inode)) { error =3D ext4_begin_ordered_truncate(inode, --=20 2.43.0