From nobody Mon May 25 01:57:45 2026 Received: from mail-yw1-f182.google.com (mail-yw1-f182.google.com [209.85.128.182]) (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 DCAB948164F for ; Tue, 19 May 2026 11:04:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.182 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779188667; cv=none; b=bYZJJByssy0Mq+8brk/aHd6Lz6a0cNlmuaKEqKlWb1/bmENGfRghzcw8ES8WsU9Oc1XsMoVETKczN9u9MXWfqk0c2o/q5FPLjq0OzLhnLaK/bFOWPPIXMfyFIR8gwMEN0xbUeEfinyD69xO626n+5Y0DALDKxPjlgLKdgBmFwRU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779188667; c=relaxed/simple; bh=q0QaQO++/PvA1DQe3ls4tZMPt5G9WPx1L4vtJDSJKXI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=fMZ+bgyZJKcM3d7PySAV1IL56nXMXzkl+jAqDnHDlWeVOaVF669vjHIs3D2Enc+BWRL7MCDfqRx6hRYpkPeSfmzpM85nv2/2RtEThH7eHhlCb/5e7orq3TQWfLRxMO53Mhewad95J1z7lhADm/h2j6WWheHfgEowSpDtwx9+izY= 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=pEYKhaYs; arc=none smtp.client-ip=209.85.128.182 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="pEYKhaYs" Received: by mail-yw1-f182.google.com with SMTP id 00721157ae682-7c58e6eb3edso28629107b3.2 for ; Tue, 19 May 2026 04:04:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779188665; x=1779793465; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=6SyXZe52KMUC2ic8Hq1mf3+02KbtP8Oos7zC9gOb7ro=; b=pEYKhaYsNiVrS6Uxo+j/UGT2ja2e6nG2yFksFP1d9amf3RJMXjRgR3CQ3sx5oxEj+m ZQ6iw5dAlsv2pUMqI6wE09y7B2jtT322nEypKsKLTizHbEex/YBhvhtBkhSmaNL1W36a Lvz/3QoTi6I0o1J77DwgH+4rDx/cXbwJybgeG0uCzMdJMViNVxqkvz05qpoHmoVagEqq tigosddlt6xpJwkxy3eY+TgpfTGPgaEhoWpoS3VmMEW/ArZJaKhFFBc4p3vsqezCNJXA BhceQ4h5neSKiYNGizFpsLMBVz05rb4qsZ+7KCYHRdh05xnAl+irMf7m2GTkyxrhJYwf oJoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779188665; x=1779793465; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=6SyXZe52KMUC2ic8Hq1mf3+02KbtP8Oos7zC9gOb7ro=; b=kdyc6qu7oVJX1mLnKysUW9NuD1uk4OqWsUBpvhw8zA+xgeLZv5O18+Q4jLrcgZEJI5 psOLghXnKlZ0zaZViSVjuEKRPHYZpwEsZauSQ7duelBE3/savatc6j9BG+/v/hFszdK0 paXgz0LM19+kk5LJDe8mTu+lRJlz0+9jifam9KmmCRh2PAGqkUTOzhR5dIdcnYSRMmSX c5PQTm5XZ0e3gprzb8h1Nk3+/auJQBcyvlGcTOob0DGvme0SullYlN8TJ/RJGDh7K+da 8u/xeD+disMmdfTKpg0CvSU2BZd1BaTgV7UlKeVSmmm3HcA4LXMAiex3UNbEna0yhFYx U4YA== X-Forwarded-Encrypted: i=1; AFNElJ8XHCZFMZH2WRJcMKUFEwUwSd82OT7jNjd73+T8UtGBw0qwsrkGiWz77+iXYmHCISzGHJm0Uu8NWsr7kpE=@vger.kernel.org X-Gm-Message-State: AOJu0YyMbvLJGNmhNI3leuOb5akUaJV2CH2iqb8FFgjXyEg+Vgc+2hGz v0Ry9bm8+/AU/THXKk7qKwtG77zoPcTKryx4IuoztG+lmBcPGBgMW9BU X-Gm-Gg: Acq92OF6+kGvl0rDdh88qbLOhT/QYHvvQYAAd/iujmWML0MauEDg+ucYJuSzKiQ0TpE r50JoA+hriE2IvaT0Orf+L04AuiaUtzYxyB1GPsHICZegnHnCCnrrnqGHDoO/K9k7yP9S9j5074 aUFlHvEYZzGkPfkC2sjv+FdjqHKy/y/OGl9ubAndD/jqilkp16qQc02t3EFlAYFAOmlcwfuk2IS HZdDdoSrd7SR9UreM26hICP9gfQc1P55WzpteQmdzgsVHu39DhBl7eROnqYBepz6yOZFWauejTt OrtMno/SfOZkBiSLRKmQC72iY0YJyZfC0C3IAt+1ct5VQ9FzQDtrQXEcdHkQ+eIEWfqftSxs8fu FaPD9ApiLx4UUtC+No0lunpO+Ltyb0t7Jev7u2OomsR8FdUKrotC4QDa6Ep9QnwL/nzv+uCGXEr 1+pyxMxWP0zYZ8w2jRB34/GgBaAV6hvyzOAFTDtkfsd0cZ/hBWe4VTlGVBROlIJIbmK36gv44Qq YYzp+5iR690a+ZVUUphUtbNYHTDsag= X-Received: by 2002:a05:690c:6c10:b0:7bf:107b:f859 with SMTP id 00721157ae682-7c959f7e881mr226344557b3.16.1779188664814; Tue, 19 May 2026 04:04:24 -0700 (PDT) Received: from server0 (c-68-48-65-54.hsd1.mi.comcast.net. [68.48.65.54]) by smtp.gmail.com with ESMTPSA id 00721157ae682-7cc9bc0ccf7sm35206827b3.25.2026.05.19.04.04.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 19 May 2026 04:04:24 -0700 (PDT) From: Michael Bommarito To: Joseph Qi , Mark Fasheh , Joel Becker Cc: ZhengYuan Huang , ocfs2-devel@lists.linux.dev, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v2 1/3] ocfs2: reject dinodes with non-canonical i_mode type Date: Tue, 19 May 2026 07:04:02 -0400 Message-ID: <20260519110404.1803902-2-michael.bommarito@gmail.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260519110404.1803902-1-michael.bommarito@gmail.com> References: <20260519110404.1803902-1-michael.bommarito@gmail.com> 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" ocfs2_validate_inode_block() currently accepts any non-zero i_mode value. ocfs2_populate_inode() then copies that mode verbatim into inode->i_mode and dispatches on i_mode & S_IFMT to the file/dir/symlink/special_file iops; an unrecognised type falls through to ocfs2_special_file_iops and init_special_inode(). Reject dinodes whose type bits do not name one of the seven canonical POSIX file types. Use fs_umode_to_ftype(), the same generic file-type conversion helper OCFS2 already uses for directory entries, so the accepted inode type set matches the kernel file-type vocabulary instead of open-coding a local switch. Apply the same structural check to the online filecheck read path. filecheck keeps its own error namespace, so it reports malformed i_mode through the filecheck logger and OCFS2_FILECHECK_ERR_INVALIDINO instead of calling ocfs2_error(), but it must not allow a malformed dinode to proceed into ocfs2_populate_inode(). Fixes: b657c95c1108 ("ocfs2: Wrap inode block reads in a dedicated function= .") Cc: stable@vger.kernel.org Link: https://sashiko.dev/#/patchset/20260517111015.3187935-1-michael.bomma= rito%40gmail.com Signed-off-by: Michael Bommarito Assisted-by: Claude:claude-opus-4-7 Reviewed-by: Joseph Qi --- fs/ocfs2/inode.c | 36 ++++++++++++++++++++++++++++++++++-- 1 file changed, 34 insertions(+), 2 deletions(-) diff --git a/fs/ocfs2/inode.c b/fs/ocfs2/inode.c index a510a0eb1adcc..e149ccbdc03ce 100644 --- a/fs/ocfs2/inode.c +++ b/fs/ocfs2/inode.c @@ -13,6 +13,7 @@ #include #include #include +#include =20 #include =20 @@ -64,7 +65,12 @@ static int ocfs2_filecheck_read_inode_block_full(struct = inode *inode, static int ocfs2_filecheck_validate_inode_block(struct super_block *sb, struct buffer_head *bh); static int ocfs2_filecheck_repair_inode_block(struct super_block *sb, - struct buffer_head *bh); + struct buffer_head *bh); + +static bool ocfs2_valid_inode_mode(umode_t mode) +{ + return fs_umode_to_ftype(mode) !=3D FT_UNKNOWN; +} =20 void ocfs2_set_inode_flags(struct inode *inode) { @@ -1494,6 +1500,24 @@ int ocfs2_validate_inode_block(struct super_block *s= b, goto bail; } =20 + /* + * Reject dinodes whose i_mode does not name one of the seven + * canonical POSIX file types. ocfs2_populate_inode() copies + * i_mode verbatim into inode->i_mode and then dispatches via + * switch (mode & S_IFMT) to file/dir/symlink/special_file iops; + * an unrecognised type falls into ocfs2_special_file_iops with + * init_special_inode(), which interprets i_rdev. Constrain the + * type here so the dispatch only ever sees a value mkfs.ocfs2 / + * VFS can produce. + */ + if (!ocfs2_valid_inode_mode(le16_to_cpu(di->i_mode))) { + rc =3D ocfs2_error(sb, + "Invalid dinode #%llu: mode 0%o has unknown file type\n", + (unsigned long long)bh->b_blocknr, + le16_to_cpu(di->i_mode)); + goto bail; + } + if (le16_to_cpu(di->i_dyn_features) & OCFS2_INLINE_DATA_FL) { struct ocfs2_inline_data *data =3D &di->id2.i_data; =20 @@ -1624,6 +1648,15 @@ static int ocfs2_filecheck_validate_inode_block(stru= ct super_block *sb, (unsigned long long)bh->b_blocknr, le32_to_cpu(di->i_fs_generation)); rc =3D -OCFS2_FILECHECK_ERR_GENERATION; + goto bail; + } + + if (!ocfs2_valid_inode_mode(le16_to_cpu(di->i_mode))) { + mlog(ML_ERROR, + "Filecheck: invalid dinode #%llu: mode 0%o has unknown file type\n", + (unsigned long long)bh->b_blocknr, + le16_to_cpu(di->i_mode)); + rc =3D -OCFS2_FILECHECK_ERR_INVALIDINO; } =20 bail: @@ -1812,4 +1845,3 @@ const struct ocfs2_caching_operations ocfs2_inode_cac= hing_ops =3D { .co_io_lock =3D ocfs2_inode_cache_io_lock, .co_io_unlock =3D ocfs2_inode_cache_io_unlock, }; - --=20 2.53.0 From nobody Mon May 25 01:57:45 2026 Received: from mail-yw1-f180.google.com (mail-yw1-f180.google.com [209.85.128.180]) (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 48F13481FD0 for ; Tue, 19 May 2026 11:04:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.180 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779188670; cv=none; b=daITM3lG1uZdjt7c+0h6MES1j/FMA9qnCjAsilF4Kg65lEIO7+ARbPWpil/mv+l/uhu2A7fEyG1MFwuxxLE7IfbBrjjW0+sU8uLVDW2I9pRk6amPVm0+wACB0AmPGpeSPBJdMfrNkyihXYkYTIqmPdM1aRJGL0QWMAg6OIK2Eqc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779188670; c=relaxed/simple; bh=FA07lT6C4tTEVDxKP6sBgKRYzFaomS+7kWG4YIRtUto=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=QIgcaTw3bUuY2vWatXUPw8X0sjgZBpQdV7/DjT6opFSTtVKHnEwnzHbCInvXQBqL0uz5KsSrN3yPyzZkw133ehmnq+OthGJWaplOC7QzSNZgn9wy65YvVVRWb77eBWxGobavCZAKNzpKfCfYCfxnYq5Uv9x5O53Y7Ms2bSxmTNU= 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=EqKQ+dCT; arc=none smtp.client-ip=209.85.128.180 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="EqKQ+dCT" Received: by mail-yw1-f180.google.com with SMTP id 00721157ae682-7bd6f65c781so26141257b3.1 for ; Tue, 19 May 2026 04:04:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779188666; x=1779793466; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=PuiWRQBqdRLNOxJ2VaNl5btGp2aiulYiXmdelCaoF30=; b=EqKQ+dCTBmNawz3z4SNN2PCQdPqfGOKoY4u3jlk9tk9yyloS9Hg7V4Fdoq46lOgU1g BbQXAZrdhp3bgnLqzYO1kOUNUNz5ks/lexZ4j6Be2QLer0JXWnZs3AF1IsE9yXlmchyp IVSCpmY8japnhq8lQpqJ/QJryl8/p0F2af3+8aPnA0vCSBaff3PBp8O2PFvwbUUWuCf1 byC2sPBomdbQvV1JUdU0/Unb0yPzOZlBys0UOvvYTVXG8wcqUoI8EQVds6DRvq4ONaJ0 5+t+lVUcE39RusMUF5fyG6giQ7uUWSVhpAAS7c/yPqU+t3iL/K3edERyK0gYgUP4mtup 7phw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779188666; x=1779793466; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=PuiWRQBqdRLNOxJ2VaNl5btGp2aiulYiXmdelCaoF30=; b=DKfRUvbOOPhWsIy1sikmVF470hjrr7Rci6iGHuo6DwPJqrVnUHAgK1hLCqq1xLioPt 7rgevej97fMUtQ4p8GFbeCUVl3YiETOKP66Gwft34ToMAFoDKcdPF/7p97ebf8r5ATMd pnxq5IgKszBVAJpwVHXqeeUbk/O6nRH49y4Tr3xAyahbZke1KD5GOHFcJvsfvNoXG/Rt 20QE6T2FzdKEG0d+is3onkJdivh1HwRd7n2c6GmSpj/mQ5Ur67rrbQhNPd67sCv3VZr/ zQ1nTZhvlAr9wwHL2j9NTtB2rZD4lNFJ5GCAQP5X2YCP1pV/8dPYuKt+f/yVRJ39RJ8D 1xkQ== X-Forwarded-Encrypted: i=1; AFNElJ+9zl9chOUaN7UM7dNGkgzQbq5xRnoerg9tmj9MYXvmUa8+7vPP6UcGCmUm1FbMGIruMacxzKVb9hWvXmE=@vger.kernel.org X-Gm-Message-State: AOJu0YzwDfSBGdL+DO3bgXJ9wCDtcGjUwsCU3tv7jSSFp7rkL+yTWhPk 0Mwtxv+DvokT+CBpMEmpP69R/9mLRPSCjjoDaLpsA334GEL/LZkvSIEg X-Gm-Gg: Acq92OFBcXCuGuxJLohjTsf3l24CJi1tSWON+QGe5BKCo93hprOuBBsUkk71Wn+Fvfa Jgiv9u7vthDMzE3r3UKKNRuakJOcZVRMNB/I4kZteqNZROJyzDGiba6XMFoEl9YF/lWX7BK3+tO dX9pCKSVvh/BhxGTVJZMdj+axhBed7tJBszCJZkae6Xwvbg9gg3WMIn4mb259javnaNFSAqgDvN ZPWnTM9lQ6h8DnUjMbx/0XcJNDR6XKIOk3FSqmbKuq4rcuUCeHGBgs7o08431NObYroTS8W2fPi rdEju2kB8bmwm7kE2Jt3Bi070d/SD4an+l5tPDDRMj+gDyXv/d1V01TkHcM3fFIbrYD16HDlvXp FWLqaU6gE8hhx71i4D8kqnzEhzf6XfRvVxvRMcCEpQfbcL+trcAt2vvsHt7ejyKEfgYxtv70JvD SPdyJ6OBv/twRlLv+67clo4m9scKxQaBS74S9Jb+De7rKmWOcXAHXeW+HghZMrMzG9+5E6tPC72 stTZ3El2NdvbKoSMzmQ X-Received: by 2002:a05:690c:e1cc:20b0:7c7:df46:3e2b with SMTP id 00721157ae682-7c7e7e1c3c2mr143911227b3.16.1779188666185; Tue, 19 May 2026 04:04:26 -0700 (PDT) Received: from server0 (c-68-48-65-54.hsd1.mi.comcast.net. [68.48.65.54]) by smtp.gmail.com with ESMTPSA id 00721157ae682-7cc9bc0ccf7sm35206827b3.25.2026.05.19.04.04.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 19 May 2026 04:04:25 -0700 (PDT) From: Michael Bommarito To: Joseph Qi , Mark Fasheh , Joel Becker Cc: ZhengYuan Huang , ocfs2-devel@lists.linux.dev, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v2 2/3] ocfs2: reject dinodes whose i_rdev disagrees with the file type Date: Tue, 19 May 2026 07:04:03 -0400 Message-ID: <20260519110404.1803902-3-michael.bommarito@gmail.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260519110404.1803902-1-michael.bommarito@gmail.com> References: <20260519110404.1803902-1-michael.bommarito@gmail.com> 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" id1.dev1.i_rdev is the device-number arm of the ocfs2_dinode id1 union. It is only meaningful for character and block device inodes. For any other user-visible file type the on-disk value must be zero. ocfs2_populate_inode() currently copies id1.dev1.i_rdev into inode->i_rdev before the S_IFMT switch decides whether the inode is a special file. A non-device inode with a non-zero i_rdev can therefore publish stale or attacker-controlled device state into the in-core inode. System inodes legitimately use other arms of the same union, so keep the cross-check restricted to non-system inodes. Factor that predicate into a helper and use it in both the normal validator and online filecheck path; filecheck reports the malformed dinode through OCFS2_FILECHECK_ERR_INVALIDINO instead of ocfs2_error(). Fixes: b657c95c1108 ("ocfs2: Wrap inode block reads in a dedicated function= .") Cc: stable@vger.kernel.org Signed-off-by: Michael Bommarito Assisted-by: Claude:claude-opus-4-7 Reviewed-by: Joseph Qi --- fs/ocfs2/inode.c | 55 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 55 insertions(+) diff --git a/fs/ocfs2/inode.c b/fs/ocfs2/inode.c index e149ccbdc03ce..992980ea98046 100644 --- a/fs/ocfs2/inode.c +++ b/fs/ocfs2/inode.c @@ -72,6 +72,16 @@ static bool ocfs2_valid_inode_mode(umode_t mode) return fs_umode_to_ftype(mode) !=3D FT_UNKNOWN; } =20 +static bool ocfs2_dinode_has_unexpected_rdev(struct ocfs2_dinode *di) +{ + umode_t mode =3D le16_to_cpu(di->i_mode); + + if (le32_to_cpu(di->i_flags) & OCFS2_SYSTEM_FL) + return false; + + return !S_ISCHR(mode) && !S_ISBLK(mode) && di->id1.dev1.i_rdev !=3D 0; +} + void ocfs2_set_inode_flags(struct inode *inode) { unsigned int flags =3D OCFS2_I(inode)->ip_attr; @@ -1518,6 +1528,41 @@ int ocfs2_validate_inode_block(struct super_block *s= b, goto bail; } =20 + /* + * id1.dev1.i_rdev is the device-number arm of the id1 union and + * is only meaningful for character and block device inodes. For + * any other regular user-visible file type the on-disk value + * must be zero. ocfs2_populate_inode() currently runs + * + * inode->i_rdev =3D huge_decode_dev(le64_to_cpu(fe->id1.dev1.i_rdev)= ); + * + * unconditionally, before the S_IFMT switch decides whether the + * inode is a special file. As a result, an i_rdev value present + * on a non-device inode is silently published into the in-core + * inode; a subsequent forced re-read or in-core mode mutation + * (cluster peer with raw write access to the shared LUN, + * on-disk corruption, or a separately forged dinode) can then + * expose the attacker-controlled device number to + * init_special_inode() without ever showing an unusual i_mode + * at validation time. + * + * System inodes (OCFS2_SYSTEM_FL) legitimately use the bitmap1 + * and journal1 arms of the same union (allocator i_used / + * i_total counters and the journal ij_flags / + * ij_recovery_generation pair); those bytes are not an i_rdev + * and must not be checked here. Restrict the cross-check to + * non-system inodes, which is the full attacker-controllable + * surface. + */ + if (ocfs2_dinode_has_unexpected_rdev(di)) { + rc =3D ocfs2_error(sb, + "Invalid dinode #%llu: non-device mode 0%o with i_rdev %llu\n", + (unsigned long long)bh->b_blocknr, + le16_to_cpu(di->i_mode), + (unsigned long long)le64_to_cpu(di->id1.dev1.i_rdev)); + goto bail; + } + if (le16_to_cpu(di->i_dyn_features) & OCFS2_INLINE_DATA_FL) { struct ocfs2_inline_data *data =3D &di->id2.i_data; =20 @@ -1657,6 +1702,16 @@ static int ocfs2_filecheck_validate_inode_block(stru= ct super_block *sb, (unsigned long long)bh->b_blocknr, le16_to_cpu(di->i_mode)); rc =3D -OCFS2_FILECHECK_ERR_INVALIDINO; + goto bail; + } + + if (ocfs2_dinode_has_unexpected_rdev(di)) { + mlog(ML_ERROR, + "Filecheck: invalid dinode #%llu: non-device mode 0%o with i_rdev %= llu\n", + (unsigned long long)bh->b_blocknr, + le16_to_cpu(di->i_mode), + (unsigned long long)le64_to_cpu(di->id1.dev1.i_rdev)); + rc =3D -OCFS2_FILECHECK_ERR_INVALIDINO; } =20 bail: --=20 2.53.0 From nobody Mon May 25 01:57:45 2026 Received: from mail-yw1-f169.google.com (mail-yw1-f169.google.com [209.85.128.169]) (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 546FE4921A3 for ; Tue, 19 May 2026 11:04:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.169 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779188671; cv=none; b=QCiT3HorkuiNFcXt89P9GTOWpCzycap6iz+VBt78yAzcPAjcrqamJLuV6kAhInVgVPMYe9hfONNRcMpm3seG7Me/8OeIc5P3VQPHwsCYPEyE9W1aN4LKzw1mRZweLFM1oZ35iiaYld9P8zWoCUbSegU+zR2QnoGrJum8+CxWZyc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779188671; c=relaxed/simple; bh=qDrD2ZddrAheagdk3eIgrfALWmcsf4CIV39O7dRnNk8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=VsXS0ADQ9/OfpDC/YWmYHT0zvw4nspKelHYznT3atzgJ2m7PdP78KUny6/4hSffxRXTca50acp0UKiJ9vxqDAAVWg1nqOjDCgydR2hcliq3gbOtHWnXaxbEakewaubrNwnj+MC4Tt+gK8/bHrIQv4eK/cnqvdj/mEwIfKZJnsmI= 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=hYnobYIx; arc=none smtp.client-ip=209.85.128.169 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="hYnobYIx" Received: by mail-yw1-f169.google.com with SMTP id 00721157ae682-7c23248f3a3so29648697b3.1 for ; Tue, 19 May 2026 04:04:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779188667; x=1779793467; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=d+1n624ktIAXNe/+aIK+Qahfn51hvIzEeSL35mTG/Bo=; b=hYnobYIxc3S/ERDv29tAajOaM2F80ioGvZ9PK4JJZ0K9k8hNTk4pGnN0d2FmM77ZHb rehKx0QtoEovUfXjlJNNxQhgBzjM5iotRDqStmVL7AsOOIgreSdD+gIB9qBtgojp0sJd cP6xPpmEXGwv3i9m5fT/yFwKuAEts1oNhgqpE9+hhjAU0CnHB7sNSoRvAaiepnb9VEhA RCHhwgSIEkOqP9TtisW2Lp3b6h2HD+Y6KQF1xAbRCSpjP2l1F3lljmmHgvTvACQv5VtM qVz4fPpkVHC2D59Hpksv4gb/BqlwJS64O2vN47oe+W2qqfA85sUw35JrGfQtFJSY3kF6 uAjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779188667; x=1779793467; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=d+1n624ktIAXNe/+aIK+Qahfn51hvIzEeSL35mTG/Bo=; b=ArETPM6PTbZRCp/oxNcenpbRp8wzW1Bn4TdIFISvVf+BixViC5dTog7xkl0ZhzHYzz BisggZjmKODhOWAXbrzi6dFFhrOThlR198wBdsqXi3bQ4sGk5+VM2c3M7UXP5JtFsIRh Qa0gJj5HYv573BOX82qy0Se6oEQeEtoz9tOqmyUVJgPJbSPDxjXFEemPc9GKC8oVwxJ0 lq9xhqPza71L2xVcYwDoQdEx7h5vQ+SvuCvGp+sxv8ZefeiFLUrwZ/eyjbmvAxaWiSYc H2gVQjDZEZe6WvPA1PNN9w9V70Rep8hW1mTSygCpJFfJL0Bh6T6j7S66FUpgHPnuOnta OM2A== X-Forwarded-Encrypted: i=1; AFNElJ8lWwDuFyyMXJCtMuSuFmRCH+sx1XJrsbsOc+XdkUUyGs6z1GEAFWaBbOj8rucP3jba3HqnT5d0KXpFIWo=@vger.kernel.org X-Gm-Message-State: AOJu0Yxxel4Hg27wJJspERMXo+XXx5m7r6r3xVlXM9uFj14yWE9Kh6JO ltVgSE53UZqpL/Dm8v9hGRpW56F5CCocju5Hf64vCSvK786spr32q26/ X-Gm-Gg: Acq92OHe76lBf0xGwRr3xXXd1v2kxTWFYABYWbcZYFyqMoqAepzYkytZ+JUsXHwzwfg ept3wgcPR6E4+oFCwHLs6TZ9rDjltj0P/jtNF057rqGNsBKUJ5q9ZDywVr1lF+58BEPorHPmJe5 cjTKbM5hXxv+c6E8VY7HDKJM1fVcxLiZaqX+iBgNpt02VLCVwej1upaaySNlpZJ9/p0wJt+EiXb 1YILOf0Zk2Rs7Oiy3LOkJ7nmZFYfVo2fptTmp1h9Gc2rMGpF2CVQyQP2GWjJ0Y14p1y7YjC4yvO AJl/l5BI4qIezVQsjHNodLwlRlB3XpZDSxDUJnxuWjrRtmDhc38YaeKANrsFmRBUtU2viePvkGT qfTg9dKBgGz57/BsqUVfmkJxEkghFsa2f9j54IxFF6BqA1ZM0GVD/ndzJYx5Lb67xXk+06Ypc2D 7BhALRv8Eh51aD2QE1WnhevLUnavyT28E/jWDwrdQwZw1v1sMYFL3R7O6X4rANX1tagQcFSsLOD ytjs33DK8FmBAx28nhaX5pAERuiNKs= X-Received: by 2002:a05:690c:f15:b0:79f:3715:1980 with SMTP id 00721157ae682-7c95a37c674mr220804827b3.12.1779188667319; Tue, 19 May 2026 04:04:27 -0700 (PDT) Received: from server0 (c-68-48-65-54.hsd1.mi.comcast.net. [68.48.65.54]) by smtp.gmail.com with ESMTPSA id 00721157ae682-7cc9bc0ccf7sm35206827b3.25.2026.05.19.04.04.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 19 May 2026 04:04:26 -0700 (PDT) From: Michael Bommarito To: Joseph Qi , Mark Fasheh , Joel Becker Cc: ZhengYuan Huang , ocfs2-devel@lists.linux.dev, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v2 3/3] ocfs2: reject non-inline dinodes with i_size and zero i_clusters Date: Tue, 19 May 2026 07:04:04 -0400 Message-ID: <20260519110404.1803902-4-michael.bommarito@gmail.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260519110404.1803902-1-michael.bommarito@gmail.com> References: <20260519110404.1803902-1-michael.bommarito@gmail.com> 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" On a volume mounted without OCFS2_FEATURE_INCOMPAT_SPARSE_ALLOC, a non-inline regular file with non-zero i_size and zero i_clusters is structurally malformed: the extent map declares no allocated clusters yet the size header claims content exists. Keep rejecting that shape, but express it through a shared predicate so the same invariant is available to normal inode reads and online filecheck. The same zero-cluster shape is also malformed for non-inline directories. ocfs2 directory growth allocates backing storage before advancing i_size, and ocfs2_dir_foreach_blk_el() later walks until ctx->pos reaches i_size_read(inode). A forged directory dinode with a huge i_size and no clusters would repeatedly fail on holes while advancing through the claimed size. Sparse regular files remain exempt: on sparse-alloc volumes, truncate can legitimately grow i_size without allocating clusters. System inodes and inline-data dinodes also retain their separate storage rules. Mirror the check in ocfs2_filecheck_validate_inode_block() as well. filecheck reports through its own error namespace, so malformed size/cluster state is logged as a filecheck invalid-inode result rather than via ocfs2_error(), but it must not proceed into ocfs2_populate_inode(). Fixes: b657c95c1108 ("ocfs2: Wrap inode block reads in a dedicated function= .") Cc: stable@vger.kernel.org Link: https://sashiko.dev/#/patchset/20260517111015.3187935-1-michael.bomma= rito%40gmail.com Signed-off-by: Michael Bommarito Assisted-by: Claude:claude-opus-4-7 Reviewed-by: Joseph Qi --- fs/ocfs2/inode.c | 60 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 60 insertions(+) diff --git a/fs/ocfs2/inode.c b/fs/ocfs2/inode.c index 992980ea98046..432eac01c1763 100644 --- a/fs/ocfs2/inode.c +++ b/fs/ocfs2/inode.c @@ -82,6 +82,24 @@ static bool ocfs2_dinode_has_unexpected_rdev(struct ocfs= 2_dinode *di) return !S_ISCHR(mode) && !S_ISBLK(mode) && di->id1.dev1.i_rdev !=3D 0; } =20 +static bool ocfs2_dinode_has_size_without_clusters(struct super_block *sb, + struct ocfs2_dinode *di) +{ + umode_t mode =3D le16_to_cpu(di->i_mode); + + if (le32_to_cpu(di->i_flags) & OCFS2_SYSTEM_FL) + return false; + if (le16_to_cpu(di->i_dyn_features) & OCFS2_INLINE_DATA_FL) + return false; + if (!le64_to_cpu(di->i_size) || le32_to_cpu(di->i_clusters)) + return false; + + if (S_ISDIR(mode)) + return true; + + return !ocfs2_sparse_alloc(OCFS2_SB(sb)) && S_ISREG(mode); +} + void ocfs2_set_inode_flags(struct inode *inode) { unsigned int flags =3D OCFS2_I(inode)->ip_attr; @@ -1563,6 +1581,33 @@ int ocfs2_validate_inode_block(struct super_block *s= b, goto bail; } =20 + /* + * Non-inline directories must not have i_size without allocated + * clusters: directory growth adds storage before advancing i_size, + * and readdir walks i_size block-by-block. A forged directory + * with zero clusters and a huge i_size would repeatedly fault on + * holes while advancing through the claimed size. + * + * Non-inline regular files have the same invariant on non-sparse + * volumes. Sparse regular files are different: truncate can + * legitimately grow i_size without allocating clusters, so keep + * the sparse-alloc carveout for S_IFREG only. System inodes and + * inline-data dinodes have their own storage rules. + */ + if (ocfs2_dinode_has_size_without_clusters(sb, di)) { + if (S_ISDIR(le16_to_cpu(di->i_mode))) + rc =3D ocfs2_error(sb, + "Invalid dinode #%llu: directory i_size %llu with i_clusters 0 and n= o inline-data flag\n", + (unsigned long long)bh->b_blocknr, + (unsigned long long)le64_to_cpu(di->i_size)); + else + rc =3D ocfs2_error(sb, + "Invalid dinode #%llu: regular file i_size %llu with i_clusters 0 an= d no inline-data flag on non-sparse volume\n", + (unsigned long long)bh->b_blocknr, + (unsigned long long)le64_to_cpu(di->i_size)); + goto bail; + } + if (le16_to_cpu(di->i_dyn_features) & OCFS2_INLINE_DATA_FL) { struct ocfs2_inline_data *data =3D &di->id2.i_data; =20 @@ -1712,6 +1757,21 @@ static int ocfs2_filecheck_validate_inode_block(stru= ct super_block *sb, le16_to_cpu(di->i_mode), (unsigned long long)le64_to_cpu(di->id1.dev1.i_rdev)); rc =3D -OCFS2_FILECHECK_ERR_INVALIDINO; + goto bail; + } + + if (ocfs2_dinode_has_size_without_clusters(sb, di)) { + if (S_ISDIR(le16_to_cpu(di->i_mode))) + mlog(ML_ERROR, + "Filecheck: invalid dinode #%llu: directory i_size %llu with i_clu= sters 0 and no inline-data flag\n", + (unsigned long long)bh->b_blocknr, + (unsigned long long)le64_to_cpu(di->i_size)); + else + mlog(ML_ERROR, + "Filecheck: invalid dinode #%llu: regular file i_size %llu with i_= clusters 0 and no inline-data flag on non-sparse volume\n", + (unsigned long long)bh->b_blocknr, + (unsigned long long)le64_to_cpu(di->i_size)); + rc =3D -OCFS2_FILECHECK_ERR_INVALIDINO; } =20 bail: --=20 2.53.0