From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f180.google.com (mail-pl1-f180.google.com [209.85.214.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 D161B426436 for ; Thu, 2 Jul 2026 08:22:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.180 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782980541; cv=none; b=oHm2rDPXDy/g6cEaDGKwh/mrInbvV45rFoY2wj97P/qgXdLGF0VjLaMUT7V1qYLj3gyzR8lZLyCxvYWJhOoHDIS9y1wnq8RJyUXb40qYDNdjZjTaW8ukWm3fu7pT1OpVSiMJqH7xL1vy5/Sy0kjIIQ35/k0PFuJx/kI/eZ6huTg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782980541; c=relaxed/simple; bh=jzBsSOX7rKuC0DU0ptJYn1MzJwYKOpNvi0gpu+65E4c=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=JWP6IxTz65MrfDSAZcb+4OK/ART+wVIH+RxSFwP3x2m8ByRvtnbIyGTtpnRmYGBCo29xdn1qWsk+UqZVYJBUXCU6TK/hNYjk8NYDltX2Yx4QPXDveqBzWX0hQEEAmkF/80rnwhRMAruDjOL1zDHOZ9SFBQJfWjUBxiSedLRYY2I= 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=AXAplSE+; arc=none smtp.client-ip=209.85.214.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="AXAplSE+" Received: by mail-pl1-f180.google.com with SMTP id d9443c01a7336-2c9c1779fc8so8466805ad.3 for ; Thu, 02 Jul 2026 01:22:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1782980538; x=1783585338; 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=FTMF8MnBAWlilx2ysNeClr43UroMX+LYSUyIvM/sTTI=; b=AXAplSE+krlWWMsBQ3K9zcX1VS1/gshpGblr2sB02iBkM+Xhis0DpujKEd1i80lz9n PFleXQwuFssBKhmW86Beph2sY/QK9z47FW+AMj5e7mDWVVm9SWLk4ieCfGJnPpOhAZtt KnqTkhnthi+B1HBOOrIcfKnna4W9SPf3jou+Cv+MjUxg4QXFtErEFvnk2llA1g1Xk5UE Vqkaprw+nWQ3s8DYhV4azEbZ8x1vPlDl5GmMDABsCt6TG3y/xbnlILRMbxzUsNCarlQo ER5D6L4G+FkG40fv9pe/7GrJ6bWstzO8gYuTUoqmb1M87l8ZuoT6jr6TEBK0GzLyJW63 7Srg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782980538; x=1783585338; 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=FTMF8MnBAWlilx2ysNeClr43UroMX+LYSUyIvM/sTTI=; b=XWi2R+hXjmS1bs1FkZLa3mSo+J591sHYQBnH/R5/O9Nf1gC0tPL8/wXT6mvLdAL9im YQGql6CE2ptcrEzJ4zvje08LqGqrPr1T8NW1bYWL4brzBaqjSWJm5r2ngzqktRJ94Pxx 7JA1AiXyBlLcrtpeo2bMpPEehqg+Nkbq6tIMUcj+RMDV9q8ANupIXwaQrW8nJnyNJaw8 BbPujxiP/qYIFMZfrBgU/PDatG/wCid96FW5MDKoKmZHwci6L2X4cVl+Bjq6XQv2DdCb z/yUVRs73B08BVqM7LaoZmx4jgXdfJCu+1h5j0RS4PuxoWnh4vdYEAT+D8fYnDnuGY3m F0yg== X-Forwarded-Encrypted: i=1; AHgh+RqxvVRjqrqOfcu09XlUc9lF9SB/BGoi3FNKonZRC2PxNJeera71PqByTY83IrAT9X4b3iVon0t1Acl3gsI=@vger.kernel.org X-Gm-Message-State: AOJu0Yz17GkpxXGOYXbq46JBecopkcdMClpIj47vIEXa2glUCqmBilqZ 60UND0eOIyvA/bSP8k6TNIyNpjQI9DFxM+lgd5dD3VYTFihjzpX52PA1 X-Gm-Gg: AfdE7cnD8c068yXBhPO/7sczgEGM1n4RXSJ5ORvGtL3TWnXbHtWVC73/C2VfxzLrLsH XWFKmML+mUJUFtzBBVhP2qeHiy2uFMaUhjdgk0KwlnBa5zX1GL+28ISUICG1O1pQgna7j8qWl/V AG4cKHbRlJFH8BccCW57eCi7537EkHIyc35r3Zm/LLGWzuch0WWQwOfWufizXt3ImwF0LGGM1NW J9NKFz+OwftW5AouiJgG3FEBNoyjQmmzomQNkW0qyrjC07V8ENM46WnuBA5+/GtREq8K2EHB4TX Gfac1fBYhPKuCFzDRtIK3AGrU5V9d98+nyZLjn7b3EHWL2ksLATGHkEvjgTMhayt60LtVSQITwb 0EwUD0iDCKPx7p30IIcGDRLZ6Pv8D0bGBFwn6UBkDhoIiTc7GpntZSYLt3U45uzh4hpM+tdm2YD oJAoCn87Lkk3nHNBy/LyFScj4= X-Received: by 2002:a17:903:18e:b0:2c9:e86e:a9f5 with SMTP id d9443c01a7336-2ca7e73cbd7mr51924685ad.18.1782980537706; Thu, 02 Jul 2026 01:22:17 -0700 (PDT) Received: from ustb520lab-MS-7E07.. ([115.25.44.221]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2ca9a8da8aasm9875805ad.8.2026.07.02.01.22.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 02 Jul 2026 01:22:17 -0700 (PDT) From: Jiaming Zhang To: slava@dubeyko.com Cc: frank.li@vivo.com, glaubitz@physik.fu-berlin.de, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, r772577952@gmail.com, syzkaller@googlegroups.com Subject: [PATCH v2 0/1] hfsplus: validate B-tree record offset table Date: Thu, 2 Jul 2026 16:22:00 +0800 Message-ID: <20260702082201.286288-1-r772577952@gmail.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <6074d91cefcc32cb54f48a1ee214530836e6c948.camel@dubeyko.com> References: <6074d91cefcc32cb54f48a1ee214530836e6c948.camel@dubeyko.com> 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 Viacheslav, Thanks for the review. This v2 addresses your comments on the first version. hfs_bnode_num_recs_valid() takes only struct hfs_bnode and uses node->num_recs directly. I also introduce local variables around the record offset table size, hope this make the calculation easy to understand. The repeated record index checks are now moved into hfs_brec_record_valid(), and the record offset checks are moved into hfs_brec_range_valid(). The range helper checks offset order, alignment, node bounds, and that record data does not overlap the record offset table. I also make fd->record and related fields invalid when __hfs_brec_find() failed, and change hfs_brec_keylen() to use hfs_brec_lenoff() for the validated record start. Note that I kept the key length check as "keylen == 0 || keylen >= len". I think the length returned by hfs_brec_lenoff() is one record in a B-tree node, and keylen is the key portion, the remaining bytes are the record payload. If I am right, "keylen == len" would mean an empty payload and should be rejected, right? Changes since v1: - Use explicit zero comparisons for integer fields. - Only use node as parameter of hfs_bnode_num_recs_valid(). - Add hfs_brec_record_valid() for record index validation. - Add hfs_brec_range_valid() for per-record offset validation. - Reject record ranges that overlap the record offset table. - Preserve invalid fd fields when __hfs_brec_find() fails. - Change hfs_brec_keylen() to reuse hfs_brec_lenoff(). Jiaming Zhang (1): hfsplus: validate B-tree record offset table fs/hfsplus/bfind.c | 27 ++++++++++++++++-- fs/hfsplus/bnode.c | 16 ++++++++--- fs/hfsplus/brec.c | 37 +++++++++++++++--------- fs/hfsplus/hfsplus_fs.h | 62 +++++++++++++++++++++++++++++++++++++++++ 4 files changed, 122 insertions(+), 20 deletions(-) -- 2.43.0