From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f48.google.com (mail-wr1-f48.google.com [209.85.221.48]) (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 9D6B343D50C for ; Tue, 7 Jul 2026 21:38:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.48 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783460336; cv=none; b=pF8E9mbuALarwwN22c8NJ/eGZDexeqtvvTKv3k/9+6WXQt6QvH0LJJid0r9jXTWnbG17MV9Jh5Nc4tN3bUUeSReWFl+7b0LmUS5i67nPDS0A9HFhtG3NbDQ87zQJqq7gLB2dnJi3hWkHKswTQ2TYdL2A6AbHcGeK/j12PG/SBwk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783460336; c=relaxed/simple; bh=brot3bU627eibPuK843dIWAZGselX2YxoaJySxQF6fY=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=RiwCuk37wKhVnnIyN7wPS6x9AWXHAtyoavRl8mf8+QhrSd2oY6+vai9f4dbYJVNLMt6FRy3Gv9DdXA/LfkLQt+TglJsfr4DBBORdzzVUQiHwzAuft2hLSDPmfMJhqel8l5Sd5tF1OBiLVayPCeTxIMNH/aYPwxb9Un9BisvNl5g= 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=E3KWzwq9; arc=none smtp.client-ip=209.85.221.48 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="E3KWzwq9" Received: by mail-wr1-f48.google.com with SMTP id ffacd0b85a97d-47defaa012dso14681f8f.1 for ; Tue, 07 Jul 2026 14:38:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1783460333; x=1784065133; 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:content-type; bh=bNwYc1cJ0kqQCz9PMZarBbXYOPfgykvOIERr/DpxJTw=; b=E3KWzwq9FyvGUL5wXmhI7BQZspOvg8Awnrhy5AiFELw+YGrrxzC6GRnz1+nHZKLhW1 n27xQ4j7krISP1hITTvPWYrseSp8LDi2PevxMvzyKHkqSxKXpRalJUOUM4+YpZf65U0R FSoYZiQNQcIn5fWQogMPmvKyN5TQ2xodgFBihqbA8ZmbGQHRis5nIfVNghQ6bXuh+ACW zKUdFWqp+X9e+rWd2soiKibwUzSV2+NgTyQOJmjRObjMCdgDabRGcrk2K/yoKf2lQh2a hqLbwsDGcl1DatapjCoO0kv226jhePz6zNk2HCAMu7M18pCOKke8exfX6zoS83Qm4t6a 1dAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783460333; x=1784065133; 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:content-type; bh=bNwYc1cJ0kqQCz9PMZarBbXYOPfgykvOIERr/DpxJTw=; b=kibon8yRsbOmsYHmSkj55kz/kgjc++F04GzUTIL1q97gFpos5CxVkuQ8gIbMY536Yj L05yhD7mRtAjjEy5WyCBj6enOBMHMiZ7XEtl+jYdUJP6G6rie9GHS+Yy/3s8GNm2HKm+ D0hSJPlrtfXI/P07IVnam5JPHpG0cZglTrnRfXzUoR+gdCNy+Dv1/xO91sg72LCKbcqQ WnjiipuLXqyqJvI6TzcjLq2PwByqti3uqE6V8YfqPL/GCpZ8q5JSZCZtUYXq3LxzQLOz BNybtY3fRe+paS9O7BPDE9MFyXZMyEZn80iMNNetyDCceJJ9+o/i1ewWNzeplWjHPR+U CpWg== X-Forwarded-Encrypted: i=1; AHgh+RqRewJew7O8edgp9FK//fZiMW32qMyxgausXC6ivFm8rF0LlCInVUY5rA9Q6Hk/XNjn54svR79kYtNVnDI=@vger.kernel.org X-Gm-Message-State: AOJu0YxJIBeQq5IayIAWmnmoHnq6e820s89IxpuJoCw8JMVZ3YwhwWz9 Z8Yv91zsuBkaQE7d/O1HznIHzZotfoPTLhuoVbpv3RxVQsbmzFPJdGkMzJd0rObN/6w= X-Gm-Gg: AfdE7clNTlHA01jTRiDqo2whd86HvGpbG1GjfJc1kY1F+sGXf+vOeVF+XmyZ8HJ+6dV j/BXK4LM/gSEdiceepsuo1hwdArsja27JhTDyz+NB9SHj+dqBB3Mbj1QLFTm8StHtkBIZ3KmMjI 9H6cZZkYg2EjtpWzqio3tPtR68sei5uydkdxwpMbGV+VCEEIhUVkbYmmQyb6cO/JrA+9zJcwG03 pfZZEzzNEctVuGgHPdm4aT5yO+Na027ic09s6SOAgtt3IVQrwnm6/G9QnHQkq2kjMX+AgsP8hPs rglOi1G2m3vOEdfS1uFO9PKKE7X87nM/XSawh/qXGCmRZ1aNr+WCpy/uGGVfzuFqXOsx9EDMpH3 TchpGUit7oWPY+LF+Trnz9m1AfFZX4JkgCd6+8TtCYu64JpwByA6mAoFn+Nq57va4jU/FEktsit +sllOxGlwCMHxJj0uKaB3LC1ktK2ln8OYkCPi8x1bfYpfbOTT1iNpfiElzaUJC4DYjBXOQcot7X WZkXL7O5z6vpODIFFIPpkesSs3zd31tg57ba4U129B3NcQMqRLFBuhQXda2QcdsUXjAS8ukzEg= X-Received: by 2002:a05:6000:461e:b0:47d:df96:c9f4 with SMTP id ffacd0b85a97d-47de6667871mr8403779f8f.10.1783460332789; Tue, 07 Jul 2026 14:38:52 -0700 (PDT) Received: from instance-20260604-012959.europe-west1-b.c.project-2c9d95d2-bf4e-4d5a-ac6.internal (250.69.76.34.bc.googleusercontent.com. [34.76.69.250]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-47aa039bcdasm38086196f8f.21.2026.07.07.14.38.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Jul 2026 14:38:52 -0700 (PDT) From: David Maximiliano Hermitte To: Viacheslav Dubeyko Cc: Jori Koolstra , George Anthony Vernon , Tetsuo Handa , John Paul Adrian Glaubitz , Yangtao Li , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, syzbot+97e301b4b82ae803d21b@syzkaller.appspotmail.com Subject: Re: [PATCH v3 RESEND] hfs: validate catalog CNIDs before instantiating inodes Date: Tue, 7 Jul 2026 21:38:34 +0000 Message-ID: <20260707213834.431563-1-davemadmaxxx@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 Hi Slava, Thank you for the review. Yes, I agree that the initial length validation can be simplified to: rec_len = fd->entrylength; if (rec_len <= 0 || rec_len > sizeof(rec)) return -EIO; I also agree that, for the fixed-size file and directory catalog records, the checks should require the exact record size: rec_len != sizeof(struct hfs_cat_file) and: rec_len != sizeof(struct hfs_cat_dir) Regarding hfs_write_inode(), I intentionally left it unchanged because the patch was trying to reject invalid CNIDs at the catalog lookup and inode-instantiation boundaries, before a corrupted inode could reach writeback. However, I agree that an additional validation there may be useful as defense in depth. Would you prefer hfs_is_valid_cnid() to be checked in hfs_write_inode() as well, and should that check precede the existing BUG path while otherwise leaving its behavior unchanged? I will prepare the next revision after your guidance on that point. Thanks, David