From nobody Sun Feb 8 06:55:08 2026 Received: from mail-pl1-f171.google.com (mail-pl1-f171.google.com [209.85.214.171]) (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 A7E912561A2 for ; Fri, 12 Dec 2025 05:21:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.171 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765516904; cv=none; b=OLtDoNkwNFNedx02LYCwr9I2sEN2bwbWNlJLdqJy8sLncKpA7fprh9wLCztJUm4uMkhwOTSjm+D5xoEgjHx0ZqULmSxcg2jniEqZ35jzXUccN+hxjCFV/v7j/xMGK3tuxigk+KVp7KqB3eG/pepCK7TOfn6zVUHE2CMeA3RcM1o= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765516904; c=relaxed/simple; bh=S1DBotLlYvk9k0AmyT3FE9+aD8AH8zQWJA8o4UHqmTI=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=Xt+W9Sa4BOQUkXCf+2ycJLZFYyRTZrFM/uOhoJEVyasVIsxBzGfL4/iCIdI1oYtA+OC+e0zE81V/6RTYDAP0L6z1TGTqIkESsiz4Lb2V56lAU2WA2Z7QrUiEYM28iA30uJL/CYVW54jsdOZOC4Vi8iIndIkglh4nkioPJDP8oSM= 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=Fu3VBmoV; arc=none smtp.client-ip=209.85.214.171 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="Fu3VBmoV" Received: by mail-pl1-f171.google.com with SMTP id d9443c01a7336-29555b384acso8750875ad.1 for ; Thu, 11 Dec 2025 21:21:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1765516902; x=1766121702; 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=v+Ija+pI/LjKCThcAVpVF5sRX9mTT5SVCKMoQmCEL8w=; b=Fu3VBmoVCi3Tl+kPaBwcoU0nZv0/P+PmCDs0gJ+CWqJ2k3AuvsCsLXMdWuavOYrvNo 3YgVtj3uE+cZ088mH4qV9u4E8SXnKr+7vLih8ET5qujE6d+rWF4cVLrhKTex3UzCXhYN qDtP0C5L7R5lF6EDzwtg3DKeqcGbdsLwMmr3hWIWqDrzQjipP0rs6+Dcg+VPmpJfDDy8 5vI3bzBCEmcNbhNklW5hYfhA+xj+5xK/ZJf+l15wGEt6UXKx7ifelHNpTuUhMMG8vtD2 7QouG4lWIeBF8/o97cT4/f3CBUc3zfg7SdJZBgh+lG7QtmEQPTl6aUO2IUEqTiK7YpH6 xz8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765516902; x=1766121702; 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=v+Ija+pI/LjKCThcAVpVF5sRX9mTT5SVCKMoQmCEL8w=; b=HIrDwChATVeptSQWDqC8YMNvGHLJzwEctTrs7Qq7vfw3IaPZzPeLufL7lFvfIjNVSi jGP8kpPeyAEeMTEI/WfuwxtZsfUr4oX82ehA6dLED7JeHWKj1TOmp8+wFOy1iQCcGHTZ xuimiIQEqiuPtPICuP8GzvMihRbEZaPj+51CGD2iMpu3HxgEQMZ+s0ehtHDDg0pu0j8m AZWdxaUGvtoD2ZrqlwcOSaaX4T4r3p+1VeYY5V13s04qHrCBc1rK7rsxa8AYY+Y6Ard/ CNOlzdMKjaF+8nFDchOvRR8FdhZw0XqCMlmBnquGYFmwigLO03X0w4Hb/oZIMBjnZYvD 0Tzw== X-Forwarded-Encrypted: i=1; AJvYcCWSjDrZqhPP5Ia4m328zrVYTVWMg3iu+la/ADucqu1KOU7MEQQTV8xjBmFMsjix/8Iwc6L6OSuuYMJVzzg=@vger.kernel.org X-Gm-Message-State: AOJu0Yw/3irfAl3tnW4PE4lEy1ZYehx31Z7GMNiRGPVQBw7bTnWD9RO+ 0vfNXROV6ggm2eYiPAXicL0FAG7YZpnQWR4UB1azTVqh7TsschkLmkvz X-Gm-Gg: AY/fxX7UWZ+sVfUCQiNwDGQxBuytCDG6Se3DavJ1dcUpxPTzTx5SpVlrCeoZWS9Zb7Z UPi5V4VydLCkkgBcRXkCHs8gaMDp8t3vJAZZHDruLshpRCJspUu9bsyzlSzkEY3gvVikprvX+i2 fBqzfkVfSsE8+E9qmQKX/KtOe5zuzfvshAJ+oUent5L1C5v5G6sKkiQAopdilql8/9/D+WC0y2/ Uslmb6/nqpRKFjgQV1fAOoimPjEw9r4X0w3WWUZtDrfDyPaTZS7UmAcqANOSJxLacvjRXnqNgBt iJHrltWvjUnNLd0uDzk3I5J2lO9Zg+qEEsLnYksGgVcUpjsyDbIGijeDBnx2JPAoTDmZF0cynKE 4dFJQF3DSvcwPvHzZNWnP8AwcLDNzlelRoLpPeS7umWtg1EFjevzydl3if9jqb8nkTEySTDCGMv u3BXJpOxSRpnTkYR7O8R/FGPL+fHWgIF1bu3eNdWdf5iCHtbT5qsoO7rvdcG5scjhmSr8= X-Google-Smtp-Source: AGHT+IFYcspdGY3KrYZFsnEAJjmaELuSHQEgRKd8drqhsWxwvdRTL/m1yYypBnXAlV7bm7MWBKsspw== X-Received: by 2002:a17:902:c402:b0:294:f1fa:9097 with SMTP id d9443c01a7336-29f2403930emr12009795ad.34.1765516901730; Thu, 11 Dec 2025 21:21:41 -0800 (PST) Received: from deepanshu-kernel-hacker.. ([2405:201:682f:389d:aae7:653e:9526:17a4]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-29eea03fa70sm41291565ad.69.2025.12.11.21.21.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 11 Dec 2025 21:21:41 -0800 (PST) From: Deepanshu Kartikey To: mark@fasheh.com, jlbec@evilplan.org, joseph.qi@linux.alibaba.com, heming.zhao@suse.com Cc: ocfs2-devel@lists.linux.dev, linux-kernel@vger.kernel.org, Deepanshu Kartikey , syzbot+c897823f699449cc3eb4@syzkaller.appspotmail.com Subject: [PATCH v3] ocfs2: validate inline data i_size during inode read Date: Fri, 12 Dec 2025 10:51:32 +0530 Message-ID: <20251212052132.16750-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" When reading an inode from disk, ocfs2_validate_inode_block() performs various sanity checks but does not validate the size of inline data. If the filesystem is corrupted, an inode's i_size can exceed the actual inline data capacity (id_count). This causes ocfs2_dir_foreach_blk_id() to iterate beyond the inline data buffer, triggering a use-after-free when accessing directory entries from freed memory. In the syzbot report: - i_size was 1099511627576 bytes (~1TB) - Actual inline data capacity (id_count) is typically <256 bytes - A garbage rec_len (54648) caused ctx->pos to jump out of bounds - This triggered a UAF in ocfs2_check_dir_entry() Fix by adding a validation check in ocfs2_validate_inode_block() to ensure inodes with inline data have i_size <=3D id_count. This catches the corruption early during inode read and prevents all downstream code from operating on invalid data. Reported-by: syzbot+c897823f699449cc3eb4@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=3Dc897823f699449cc3eb4 Tested-by: syzbot+c897823f699449cc3eb4@syzkaller.appspotmail.com Link: https://lore.kernel.org/all/20251211115231.3560028-1-kartikey406@gmai= l.com/T/ [v1] Link: https://lore.kernel.org/all/20251212040400.6377-1-kartikey406@gmail.c= om/T/ [v2] Signed-off-by: Deepanshu Kartikey Reviewed-by: Joseph Qi --- v3: - Folded new check into existing OCFS2_INLINE_DATA_FL block (Joseph Qi) v2: - Removed unnecessary S_ISDIR() check since OCFS2_INLINE_DATA_FL applies to both directories and regular files (Heming Zhao) - Fixed checkpatch.pl warnings --- fs/ocfs2/inode.c | 25 +++++++++++++++++++------ 1 file changed, 19 insertions(+), 6 deletions(-) diff --git a/fs/ocfs2/inode.c b/fs/ocfs2/inode.c index 8340525e5589..77f73fa663b7 100644 --- a/fs/ocfs2/inode.c +++ b/fs/ocfs2/inode.c @@ -1486,12 +1486,25 @@ int ocfs2_validate_inode_block(struct super_block *= sb, goto bail; } =20 - if ((le16_to_cpu(di->i_dyn_features) & OCFS2_INLINE_DATA_FL) && - le32_to_cpu(di->i_clusters)) { - rc =3D ocfs2_error(sb, "Invalid dinode %llu: %u clusters\n", - (unsigned long long)bh->b_blocknr, - le32_to_cpu(di->i_clusters)); - goto bail; + if (le16_to_cpu(di->i_dyn_features) & OCFS2_INLINE_DATA_FL) { + struct ocfs2_inline_data *data =3D &di->id2.i_data; + + if (le32_to_cpu(di->i_clusters)) { + rc =3D ocfs2_error(sb, + "Invalid dinode %llu: %u clusters\n", + (unsigned long long)bh->b_blocknr, + le32_to_cpu(di->i_clusters)); + goto bail; + } + + if (le64_to_cpu(di->i_size) > le16_to_cpu(data->id_count)) { + rc =3D ocfs2_error(sb, + "Invalid dinode #%llu: inline data i_size %llu exceeds id_count %u\n= ", + (unsigned long long)bh->b_blocknr, + (unsigned long long)le64_to_cpu(di->i_size), + le16_to_cpu(data->id_count)); + goto bail; + } } =20 if (le32_to_cpu(di->i_flags) & OCFS2_CHAIN_FL) { --=20 2.43.0