From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f170.google.com (mail-pf1-f170.google.com [209.85.210.170]) (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 7F244392811 for ; Sat, 9 May 2026 09:10:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.170 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778317822; cv=none; b=oF3V09Gj8WA3Ziald0EQVCxiEq9Og6yzf3kCXcrdRGhOS7DxFZj1nehwflImxqyQBSDnoKugFFr9QtVKbw3yjPonbl75czJvYnWRS6xS/TWziRui6lNrcp4/oGq7kEcrBa5iUes4t7gRUE5RnPl4eU8BdAZvPcaYoHN1wji1OUU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778317822; c=relaxed/simple; bh=WKWdM12bQXy2amWAqjn3073rgASxZAw+mgRRdxe7iKU=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=cAfd4DY/yUU+X7eoS1cZHS6Q5wFxR/xdYN55e+uge4H1H4FfYFK5rSPz/rFIcbKN0kESNu37RAiUY0fAKNutUtcyVpBfBXSEnR4t3S9HElEv2XKlcCL/bdzTQmqOAH7l5GhgA2lZLBLYEqOzyaQaTnP7/Hp3WgA5k13TRze1/v4= 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=BribmHWa; arc=none smtp.client-ip=209.85.210.170 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="BribmHWa" Received: by mail-pf1-f170.google.com with SMTP id d2e1a72fcca58-83659d38e38so1288101b3a.1 for ; Sat, 09 May 2026 02:10:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1778317817; x=1778922617; 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=li5Xt1PaINpaL2UPymHHMMrcfub/KFmvLpc/g8W+eII=; b=BribmHWaGgir0tR4EJ8MwZebMgX3DzVJMrbO48KUZjvnyG1k8wrtamayW85qjrUrqs G4yxKfz8vWVrc4tmAgO9z5TINs6MQ7oVuFGHEZJ8J0ypcrlSHAC8T5TEWXnrT+EvX5MT MtsMnDm0MJk/Zdw65GRzDuGBhBP5wD6AOCX/uGpvyZdOEbQWBLnkil+QafPmEHBl7pUX Gc2jnUzvvvBT+WG3vSSyYXrJvyD1oaWVZpgJExs7UIYiltcahgkhQOImvXDA5kMj0by0 TzDG3jzkwwPc6c3Qpw/GUV2fqgB3IdWGyt+9oY0fdtSoPXQc3nECMphkpc0bA+vIWG33 o0HQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778317817; x=1778922617; 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=li5Xt1PaINpaL2UPymHHMMrcfub/KFmvLpc/g8W+eII=; b=jlCPLMN/M4WeW/XMA6XkuuWSvEbq/Gj1ysKFPnlc5uJFgiLXq1EThJ/qrXamDROyeN Hoj9+RD3O0/BK4N80mpVvNm3Y5KwLf7ZiqP+Z+2lbaSvJ6EYduB41gamXpv7KblaOypT uTjN/5QdS5yfUQqZcgkpa8CmNN5hZWcPs/seyVbb7xwsYAqs9XXmsEJlKcolkEe/5oJV PvTNKNI8uuWIDw+q5QGGOYpzluTNtClCBai3HzYANYdM2Nf4kEpP4WjXntcSXmO1ZCNf POpyF4bRTrWCXoebRU9NPOKf1M3Jv6GzUiQFdZ4xOZcgjXmc4HvGS5+Qw2F8U322dwTw YaWg== X-Forwarded-Encrypted: i=1; AFNElJ/eQu/9CIeIVf5e7xa98ypdjRQRaNMqAsI9nxClFoP7oQCn0RWwRXrHNLskGum5tr+00k0srZZExXZ1KwU=@vger.kernel.org X-Gm-Message-State: AOJu0YyTNTHuts7dzirpBjZUVnI2OUoMwbM9QQx8ah7K2TgMEwQU/fV3 lJmFgRKfPvToLd3ERoubUVubCL3jv2fo5q8sczpO/5yRs9z3ecPx+16CJZaz5ErxwMQ= X-Gm-Gg: Acq92OHyJ0Pjif3roXNmXid0MTuC75dhO2bA3XEvLnS3mfuYdXx1tK3TxdSgYgRcUQY 44bb1PC1vlWfIAwYWv3dtW0/xAFLP7qaDat63MZ1c4Obxt+GL9HKKLcBAhguBTMNeOqkcqpGodh cFLR1nrlK1SK0GfJBbaBrdU1KpBWq5FZ6b4kfRRte6MFcEZc3k3OMESsLg38qOyqTJewLU7mryS wLkUQVajbjiljpGq6+zEoYae74ETgqWTtdAopzewe/S9cb9kCppZgCiEdzdRGzbJRoPWLXqUHHo PBoFa4w4OWhyiEDUGQrQtxOsMTEao9wmv3eB09BKY0KjlyA/J/z5FoY9utCfvnuK7V/eIhF/6Fo OxHxqj+OuvqGEV/jJ92MiNAfo/+Xh18cXcWp4W2QBbQ1MIbvsSfCDecxXnK1+HiGgg1YnWmYbw0 yHvk70FdwQAzn4MpH6pkvey8Fu3BMbYRQON/l5bZlOum+BdKY4KnmsM266Aebgf9q6QeWMOullD Hes X-Received: by 2002:aa7:88d6:0:b0:82a:6852:559e with SMTP id d2e1a72fcca58-83a5b8d8905mr15413203b3a.12.1778317816876; Sat, 09 May 2026 02:10:16 -0700 (PDT) Received: from gmail.com ([103.172.182.26]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-83965d35b3bsm13529609b3a.24.2026.05.09.02.10.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 09 May 2026 02:10:16 -0700 (PDT) From: ZhengYuan Huang To: mark@fasheh.com, jlbec@evilplan.org, joseph.qi@linux.alibaba.com Cc: ocfs2-devel@lists.linux.dev, linux-kernel@vger.kernel.org, baijiaju1990@gmail.com, r33s3n6@gmail.com, zzzccc427@gmail.com, ZhengYuan Huang Subject: [PATCH] ocfs2: reject inconsistent inode size before truncate Date: Sat, 9 May 2026 17:10:04 +0800 Message-ID: <20260509091004.758218-1-gality369@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: 8bit [BUG] openat(..., O_WRONLY|O_CREAT|O_TRUNC) can hit: kernel BUG at fs/ocfs2/file.c:454! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI RIP: 0010:ocfs2_truncate_file+0x1204/0x13c0 fs/ocfs2/file.c:454 Call Trace: ocfs2_setattr+0xa6d/0x1fd0 fs/ocfs2/file.c:1212 notify_change+0x4b5/0x1030 fs/attr.c:546 do_truncate+0x1d2/0x230 fs/open.c:68 handle_truncate fs/namei.c:3596 [inline] do_open fs/namei.c:3979 [inline] path_openat+0x260f/0x2ce0 fs/namei.c:4134 do_filp_open+0x1f6/0x430 fs/namei.c:4161 do_sys_openat2+0x117/0x1c0 fs/open.c:1437 do_sys_open fs/open.c:1452 [inline] __do_sys_openat fs/open.c:1468 [inline] __se_sys_openat fs/open.c:1463 [inline] __x64_sys_openat+0x15b/0x220 fs/open.c:1463 ... [CAUSE] ocfs2_truncate_file() treats di_bh->i_size matching inode->i_size as an internal code invariant and BUGs if it is broken. That assumption is too strong for corrupted metadata. The dinode block can still be structurally valid enough to pass ocfs2_read_inode_block() while no longer matching an already-instantiated VFS inode. On local mounts, ocfs2_inode_lock_update() skips refresh entirely, so truncate can observe the mismatch directly and crash instead of rejecting the corruption. [FIX] Turn the BUG_ON into normal OCFS2 corruption handling. If truncate sees di_bh->i_size disagree with inode->i_size, report it with ocfs2_error() and abort before touching truncate state. This keeps the fix at the first boundary that actually requires the sizes to match and avoids widening checks into hotter generic inode-lock paths. Signed-off-by: ZhengYuan Huang --- diff --git a/fs/ocfs2/file.c b/fs/ocfs2/file.c --- a/fs/ocfs2/file.c +++ b/fs/ocfs2/file.c @@ -444,15 +444,17 @@ int ocfs2_truncate_file(struct inode *inode, int status = 0; struct ocfs2_dinode *fe = NULL; struct ocfs2_super *osb = OCFS2_SB(inode->i_sb); - /* We trust di_bh because it comes from ocfs2_inode_lock(), which - * already validated it */ + /* + * ocfs2_inode_lock() validated the dinode block, but truncation + * still needs to reject an inode state that no longer matches + * di_bh. + */ fe = (struct ocfs2_dinode *) di_bh->b_data; trace_ocfs2_truncate_file((unsigned long long)OCFS2_I(inode)->ip_blkno, (unsigned long long)le64_to_cpu(fe->i_size), (unsigned long long)new_i_size); - mlog_bug_on_msg(le64_to_cpu(fe->i_size) != i_size_read(inode), - "Inode %llu, inode i_size = %lld != di " - "i_size = %llu, i_flags = 0x%x\n", - (unsigned long long)OCFS2_I(inode)->ip_blkno, - i_size_read(inode), - (unsigned long long)le64_to_cpu(fe->i_size), - le32_to_cpu(fe->i_flags)); + if (unlikely(le64_to_cpu(fe->i_size) != i_size_read(inode))) { + status = ocfs2_error(inode->i_sb, + "Inode %llu has inconsistent i_size: inode = %lld, dinode = %llu, i_flags = 0x%x\n", + (unsigned long long)OCFS2_I(inode)->ip_blkno, + i_size_read(inode), + (unsigned long long)le64_to_cpu(fe->i_size), + le32_to_cpu(fe->i_flags)); + goto bail; + } if (new_i_size > le64_to_cpu(fe->i_size)) { trace_ocfs2_truncate_file_error( (unsigned long long)le64_to_cpu(fe->i_size), -- 2.43.0