From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f50.google.com (mail-wm1-f50.google.com [209.85.128.50]) (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 5FE4C3B52EB for ; Fri, 12 Jun 2026 16:21:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.50 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781281277; cv=none; b=avqHLhYkAwVDB+yacnj9BKy8lwH0dyJ4ERnglhiINa018qQqtbMcrJAgm+pd2RediADKfc4HYP12iOJg9PUbCeieB0427MjW2EX8nq2fv57+RmsadJdHCRUsSbmwrHGcaRlc8bsMP2NRQCi2KZODfyb9z5twJRZkU1+vu95QuJQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781281277; c=relaxed/simple; bh=389ZRsl6oAV6U69C4rhBAu5KlNKEA5xSCzZTIbr1aZs=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=A3f5Nz6H9W9mBm6ezGrioGM0ibJq9ZDt98RqMJfenBPIp10WAWXqkE53dSAoG4dlwpeQ+9ON960spl9EmkSt06MaXR1rhVqeBMzzMYeEaNEZEYL2GYiQDy1rSfZTd4NUprVO91tYwobGaJAqfClAs/ZtagwF3whXLB8WrdlyQ5s= 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=YR9TQngW; arc=none smtp.client-ip=209.85.128.50 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="YR9TQngW" Received: by mail-wm1-f50.google.com with SMTP id 5b1f17b1804b1-490aaeabdb4so8182935e9.1 for ; Fri, 12 Jun 2026 09:21:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1781281269; x=1781886069; 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=xDOccp5+lRvv1suHq8/ojoYasAfDQKeRBKLjPPl/9pM=; b=YR9TQngWpA6NidOFtC9WZyNIOj3mX308cwzjnNK7X15BHmj6XhTogOSBLcffjETLBJ d0mSNoUcsfWYBB6nJGpLlrbFAyqJ7aN2191jVy15cqqAPAe4CVF7jhrhLi56RVUrGR36 sj9/Fph9J5m1cWDoweP2DegdFjmYhvkLyBttJob8Trv8wHltiRhVgymOLGh24C7NhGXa +EbedRyi9YTCYachzDdOBIFDCUPwyglgHiwJFn46yKeIl+/tULoDAz4me+SonsvSe3wQ bWCcmUy/nm5PWLQrFI+Ef/n+pxiW3FzN9CZ71ReSY4rHBx6Ws7M+pzjjOWXPRgtpbZOO rjIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781281269; x=1781886069; 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=xDOccp5+lRvv1suHq8/ojoYasAfDQKeRBKLjPPl/9pM=; b=PwU7WEgQ4odOBqSqcCE7g1yJAhf64BSWdvwUgTeo9Fw4k3LLAOK7JwDOco8JTQBlv1 8TpyzGuHmDn0cZmRBUTbW32b+4NeUtWUGX3L5PD2I1e5vk/RgTS6B1j9etjMKUiww+0x zgGMs5t8Ynkuvf6bKmAEhanbWN+PcBpGa4jdnNA7/v5AhpFHvkr+gYwsbjNaAj5k6rru 67CurnihEHV6lVbuS1YWJ7nY5gl9GtsiHbpXieNv32zWwvA1Ebm2vdLj32XaPaW434Yu FNtmNaIIdjiJMBjfNju5hHXFdp+q9ROeqTsmHeX0ceAgLeXwdqDOYOG6AZBVs1tjjT/h f18w== X-Forwarded-Encrypted: i=1; AFNElJ+VBkhsy2YYaemLPgMX+LIduhRSAGLvD8aI2d42J0icDho5JHeZMJ2Pwb2wPvBe0rHK3k2t2meZRXA/oro=@vger.kernel.org X-Gm-Message-State: AOJu0YzFXFSwIKhxdoNnoPtSH9vxtQvJv9qDPPYdg7b9518yOpR9hRfw TPuRzlBchl54Iz9ZkBs688OzLE+ePJBAU7iDQQqQNESZYMZJsT1AnXNa X-Gm-Gg: Acq92OFxesNr3D6yFdIQELh9ggj/SR3j+kF//Gug32oLOl8i1BaEHshQuJAOhHVOwZV nDM0k+l481trmdWkv6W+QxvREcaUOJN5WXNR8EjTwU1MY/So+uxTkdnp9NTj9ksZW3ZgffciQ8I zyFhy1PbTVtYTX6joWtCHPzqLYkx9y90sEUme1vZHhjLyfrsd3uyetO6+FO4DljHFQJJviDRJES KQAyzFCMDUwFLfelVPca47Hl3VQnWcKUSWmLVaXnx3WRCoJ4+MxGopm7bP70j9BNj6cHCoxDC1+ u+gky7/cQy7SPamKS0Qv0GPzKcLb8WIphDWMSydPqf+NCKLunYdQGDBZpGFRgdYedUwvammauZ0 3T03jn1LAQCwN20DLf6O8z5/1gFF23di6G5uvDzeGryiGY3K+ddiJYDJYJ8YpxqX+2tZB8aAR37 xMEHL8AP3GU1b5uADJdhVCXaG8rPuJwScTYlKLt3eAZK1Ds3x5+37RAjwLBuqTpDyse+1TDhN8B i6MKGfsh08mXq3Pn3DL/0DtzigaKTI+BKLwPCx4+7KjlsjXwIo/aTrhxeFwvZaPOG5Bbya2LI9W 2mCw0nS1jQ== X-Received: by 2002:a05:600c:17d5:b0:490:b4e5:ce7e with SMTP id 5b1f17b1804b1-49220104e46mr950365e9.25.1781281268491; Fri, 12 Jun 2026 09:21:08 -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 5b1f17b1804b1-490ea4a399fsm57899195e9.0.2026.06.12.09.21.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 12 Jun 2026 09:21:08 -0700 (PDT) From: David Maximiliano Hermitte To: Viacheslav Dubeyko Cc: John Paul Adrian Glaubitz , Yangtao Li , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, David Maximiliano Hermitte Subject: HFS syzbot BUG: test patch validating metadata before hfs_write_inode() Date: Fri, 12 Jun 2026 16:20:43 +0000 Message-ID: <20260612162043.1524591-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, I followed the direction you pointed out and tested a small HFS validation patch for the syzbot crash path. This is not intended as a final upstream patch yet. I am sending it as a test patch to demonstrate the crash direction and to ask whether this is the right validation point. If the direction is correct, I would appreciate guidance on the preferred upstream placement and syntax before a formal submission. My understanding is that the BUG() in hfs_write_inode() is the endpoint, not the root cause. This test patch keeps hfs_write_inode() intact and rejects corrupted HFS metadata earlier in hfs_read_inode() and hfs_brec_read(). Local QEMU result: BEFORE_UNPATCHED: - repro_started=true - kernel_bug_seen=true - verdict=BEFORE_BUG_REPRODUCED AFTER_V04_PATCHED: - repro_started=true - clean_hfs_rejects=50 - kernel_bug=False - oops=False - kasan=False - hfs_write_inode=False - verdict=AFTER_REPRO_RAN_NO_BUG_SEEN checkpatch.pl --strict: - 0 errors, 0 warnings The test patch is included below inline. Full QEMU serial logs are available if useful. Please let me know whether this validation direction matches what you expect, or whether the fix should be placed differently. Best regards, David --- test patch follows --- diff --git a/fs/hfs/bfind.c b/fs/hfs/bfind.c index d56e47b..5f56cab 100644 --- a/fs/hfs/bfind.c +++ b/fs/hfs/bfind.c @@ -174,8 +174,10 @@ int hfs_brec_read(struct hfs_find_data *fd, void *rec, u32 rec_len) res = hfs_brec_find(fd); if (res) return res; + if (fd->entryoffset < 0 || fd->entrylength <= 0) + return -EFSCORRUPTED; if (fd->entrylength > rec_len) - return -EINVAL; + return -EFSCORRUPTED; hfs_bnode_read(fd->bnode, rec, fd->entryoffset, fd->entrylength); return 0; } diff --git a/fs/hfs/inode.c b/fs/hfs/inode.c index 878535d..beefb47 100644 --- a/fs/hfs/inode.c +++ b/fs/hfs/inode.c @@ -369,6 +369,8 @@ static int hfs_read_inode(struct inode *inode, void *data) rec = idata->rec; switch (rec->type) { case HFS_CDR_FIL: + if (be32_to_cpu(rec->file.FlNum) < HFS_FIRSTUSER_CNID) + return -EFSCORRUPTED; if (!HFS_IS_RSRC(inode)) { hfs_inode_read_fork(inode, rec->file.ExtRec, rec->file.LgLen, rec->file.PyLen, be16_to_cpu(rec->file.ClpSize)); @@ -390,6 +392,9 @@ static int hfs_read_inode(struct inode *inode, void *data) inode->i_mapping->a_ops = &hfs_aops; break; case HFS_CDR_DIR: + if (be32_to_cpu(rec->dir.DirID) < HFS_FIRSTUSER_CNID && + be32_to_cpu(rec->dir.DirID) != HFS_ROOT_CNID) + return -EFSCORRUPTED; inode->i_ino = be32_to_cpu(rec->dir.DirID); inode->i_size = be16_to_cpu(rec->dir.Val) + 2; HFS_I(inode)->fs_blocks = 0;