Message ID | tencent_164AB8743976ED67863C2F375496E236B009@qq.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-51618-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7301:168b:b0:106:860b:bbdd with SMTP id ma11csp312728dyb; Sun, 4 Feb 2024 03:58:15 -0800 (PST) X-Google-Smtp-Source: AGHT+IHrOxIDFv7mbBfzc040oWdyMcnZ9w5Dr1fC35fzi3IRUu3PyPpOiuO4DeBANLJrHUweF3Lc X-Received: by 2002:a05:6e02:b42:b0:363:b21d:9d2d with SMTP id f2-20020a056e020b4200b00363b21d9d2dmr7930702ilu.11.1707047895445; Sun, 04 Feb 2024 03:58:15 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1707047895; cv=pass; d=google.com; s=arc-20160816; b=XQeKkPrfHxjD1cqvI72YNDn4fMrSnSLUzj9RM9z7gVSxJ//XhjKKTWX5uslJVzINPn 0ct7+HvU/2MM5PFFa3IfrD3ynx549AYjMOsPA104umonzbtyqWTVGYIylXWKpAy7jMxr ZQbzO+hGyZrygVgUJIoR/+oF2ScjyL0nbFdMvspQ/vKtDEgge61QJAJzgk2OCYueL/ld zXLG7sSYVNrCTrsRdZrorG17MnJmSb2kyjsyXaklG44hc3wzcA8bUoT7NBXRtLGG8Eoq kTiF4CmTa1WKnE15Te0tP8FVRfIjSW397mF5JcptRhi9AZ0TbyFmyVSYAVyn3rXtx2z5 Xc8A== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:in-reply-to:date :subject:cc:to:from:message-id:dkim-signature; bh=6IHcRw4gkKhhZegzn1OH3uiNgGEL9LqQ6Vszdi2xy6A=; fh=8hwVooGoW5nYJ6b8eFvMORhS5yKDjKo3NFzV181zQP8=; b=v45OhtJ0j9EdEdOT23om9w+qhHgdXIXvWruSEt2H/V5LRfUZ4PPVD31UWQS69wcblc XhAXVFUjmkwipLZqQH+KmGjgzcL/XiN6E/vPyZRsOUFp5vbQOf0qYANmjUvJST6e6ePL Fu20Ms+QY4WMBjG45XNe8MiImyPPeece3mv5mdxnuJCZ3FhhJyVF9IX3vHNWoVwleDn5 HPwrG45T5Bbds+sCyEUZ+EPiVPcwg7yIvnytNG8nfSa2SQMXZodljsdPLtf5MJW9XxUZ hnv+XhnSfl6oYiq4UDLtj2lBOptAfhM+niL0XNRqDixbFiHGhiFX7xCU20XHwyl5LE1+ h3gw==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@qq.com header.s=s201512 header.b=XNEtcZmM; arc=pass (i=1 spf=pass spfdomain=qq.com dkim=pass dkdomain=qq.com dmarc=pass fromdomain=qq.com); spf=pass (google.com: domain of linux-kernel+bounces-51618-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) smtp.mailfrom="linux-kernel+bounces-51618-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=qq.com X-Forwarded-Encrypted: i=1; AJvYcCVPgtkEqU9JGBK1N75Lz8+W31HV7sFUVnTz2jcoJ5W9f1TgJfoLmYo9PBdLjaPPhZ7we2RBQSkpQhhp7jpY33q+MOx84g== Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org. [147.75.48.161]) by mx.google.com with ESMTPS id g13-20020a63200d000000b005d8badaa0c8si4530295pgg.621.2024.02.04.03.58.15 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 04 Feb 2024 03:58:15 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-51618-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161; Authentication-Results: mx.google.com; dkim=pass header.i=@qq.com header.s=s201512 header.b=XNEtcZmM; arc=pass (i=1 spf=pass spfdomain=qq.com dkim=pass dkdomain=qq.com dmarc=pass fromdomain=qq.com); spf=pass (google.com: domain of linux-kernel+bounces-51618-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) smtp.mailfrom="linux-kernel+bounces-51618-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=qq.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sy.mirrors.kernel.org (Postfix) with ESMTPS id 704B5B218B7 for <ouuuleilei@gmail.com>; Sun, 4 Feb 2024 11:58:08 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id ABB89225A6; Sun, 4 Feb 2024 11:57:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=qq.com header.i=@qq.com header.b="XNEtcZmM" Received: from out162-62-58-216.mail.qq.com (out162-62-58-216.mail.qq.com [162.62.58.216]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2CDF5224CC; Sun, 4 Feb 2024 11:57:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=162.62.58.216 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707047861; cv=none; b=qjXpKVdkGb07tEOEZzEeHtZ8DOEgyhtSeOizCoH/I/+aCWtvvbWqrGxVJ17OK3lhVodUMGFURszIMB4hD5yfl5igY/DK040Rkiw8kKFdCYWrKlzK6h2H3ax6E7gXmkCnB067OxpGv+lEFV0cZBnL+KAy7ibYvAQMQZhtsjLjGUM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707047861; c=relaxed/simple; bh=NQM9ewEAOMuQm+se/Npgt3IKsTDh+L8SAE7Lj7MYFvU=; h=Message-ID:From:To:Cc:Subject:Date:In-Reply-To:References: MIME-Version; b=M2T15ekIPPEe2f1mi9Jzny1vbu+tC89IDNqvwRkLfO+dE/0oH/crSYCjW/XmDrQFw6S05Hd9iFRlAbChotCGDJIc9nALrRk+lgT/o39zbQZEY8cj3FAxf9u/uy4x/+RLqx7WpQEOhZbFlthsA0FjLh8l4FrHZGWa9wvmqcF0TF8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=qq.com; spf=pass smtp.mailfrom=qq.com; dkim=pass (1024-bit key) header.d=qq.com header.i=@qq.com header.b=XNEtcZmM; arc=none smtp.client-ip=162.62.58.216 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=qq.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=qq.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qq.com; s=s201512; t=1707047849; bh=6IHcRw4gkKhhZegzn1OH3uiNgGEL9LqQ6Vszdi2xy6A=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=XNEtcZmMiwTlKiTLDHEiKAaqccfnTRiFpyYhr1a8JFjz1ie5yikEjhQnKH7vkYgz7 CHTKs9YKDYe/Oe/xiy4i0Fw4tWPAJ9HUptw6SBNl+ztuc3D6cHwVIN/ktTUUdlAKgB 6ArgbqrGn45Etw2lb9vcqIKCT+UHGH7WUY419Tp8= Received: from pek-lxu-l1.wrs.com ([111.198.228.140]) by newxmesmtplogicsvrsza7-0.qq.com (NewEsmtp) with SMTP id CD5A4A7F; Sun, 04 Feb 2024 19:51:21 +0800 X-QQ-mid: xmsmtpt1707047481t8mna7hj6 Message-ID: <tencent_164AB8743976ED67863C2F375496E236B009@qq.com> X-QQ-XMAILINFO: OOPJ7pYMv25tidAIa0px2wHqSkcb+RQFaqhNT1q4VDqpL/DSKIkClttaSJejqZ oQkl8S+6CuffNTMlObsck87wXme7JbMeTk+lamkaB6OuCt++r5qO+ML+T8y2grA5l7dbNvacBbYh TvNDtN3P8c+7KO5ub0//l2rBseiVjyqka+F4eaFlRnZ1lsJCQBTRkWVnSLVmRNOMiazPYWkfzLe1 VuhCX/i3pKNyxllhBgUOmXp36UTFsAZb5C2qJ8Rgk5z1LeCjR/dzF8eFEzg8cEs8/i7iGdeMm+VY pkHH//REvMxc1J+ekB6sFzSG8iZn3EDvsQKh3qLaD1KKeo1xMZNe1M4jw1uFuQsqcyeqo5cpo6pz molP7pK75fiKAHEuPkp3lI7EIEnKSzow1tLQxzKPDuqXfUun3gv3NIyzFhrZK9IMkE9GcF+vXdkg GMqSls4E8Vk5u+PHo6HUwhkkh4QgIaHl/QqWigg+44Ij4zn/+JjMq+B4TuMgc6OljGqjnqFq3TKQ 5tmdo2gJ11QzuF3UMhgqNGJjAcOXYUTFhc0fyNikJ3l0B9cY8EXcvO+roWAGsc3fIdgILdym+BcT A+wviPpOlDD5yklMwEZSYOniE7yJst6BXNzcIdA7FSwSJcX89FsfsJvBH+fJM2c+X8zfovJ8AkD6 u/H9fjt4EbaBE50Z+GnW5cDEaFVWIPaQgPcVXQQrOxuNok8L413CTapaPGfC/1LPX6B59TlAMKJ0 b0wTGQqh05W4W5rCHrKDT0k6xWsZgo5af+NrMWtskF6DYYS1nEK6xu8sLNDz/Dl5j33Z6rhqqrmA yAEG91SypdEb/Bq9p5t+p3ExNFsmy1OuLIZih4NWp1Iy4Wqyf6NMwUbLVYBG2HSzO/iEnqGF17RS 8uVMkuen2XwJt7pZN5W7PVpUtZLQIe8eCjmbgkGxxN11/+Gi8gTP6grpwVd19sOHSEQfPb3kL+RO N35bq/MNQ= X-QQ-XMRINFO: Nq+8W0+stu50PRdwbJxPCL0= From: Edward Adam Davis <eadavis@qq.com> To: syzbot+57028366b9825d8e8ad0@syzkaller.appspotmail.com Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com Subject: [PATCH next] hfsplus: fix oob in hfsplus_bnode_read_key Date: Sun, 4 Feb 2024 19:51:22 +0800 X-OQ-MSGID: <20240204115121.1906264-2-eadavis@qq.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <000000000000c37a740610762e55@google.com> References: <000000000000c37a740610762e55@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1789969453669246142 X-GMAIL-MSGID: 1789969453669246142 |
Series |
[next] hfsplus: fix oob in hfsplus_bnode_read_key
|
|
Commit Message
Edward Adam Davis
Feb. 4, 2024, 11:51 a.m. UTC
In hfs_brec_insert(), if data has not been moved to "data_off + size", the size
should not be added when reading search_key from node->page.
Reported-and-tested-by: syzbot+57028366b9825d8e8ad0@syzkaller.appspotmail.com
Signed-off-by: Edward Adam Davis <eadavis@qq.com>
---
fs/hfsplus/brec.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Comments
> On 4 Feb 2024, at 14:51, Edward Adam Davis <eadavis@qq.com> wrote: > > In hfs_brec_insert(), if data has not been moved to "data_off + size", the size > should not be added when reading search_key from node->page. > > Reported-and-tested-by: syzbot+57028366b9825d8e8ad0@syzkaller.appspotmail.com > Signed-off-by: Edward Adam Davis <eadavis@qq.com> > --- > fs/hfsplus/brec.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/fs/hfsplus/brec.c b/fs/hfsplus/brec.c > index 1918544a7871..9e0e0c1f15a5 100644 > --- a/fs/hfsplus/brec.c > +++ b/fs/hfsplus/brec.c > @@ -138,7 +138,8 @@ int hfs_brec_insert(struct hfs_find_data *fd, void *entry, int entry_len) > * at the start of the node and it is not the new node > */ > if (!rec && new_node != node) { > - hfs_bnode_read_key(node, fd->search_key, data_off + size); As far as I can see, likewise pattern 'data_off + size’ is used multiple times in hfs_brec_insert(). It’s real source of potential bugs, for my taste. Could we introduce a special variable (like offset) that can keep calculated value? > + hfs_bnode_read_key(node, fd->search_key, data_off + > + (idx_rec_off == data_rec_off ? 0 : size)); I believe the code of hfs_brec_insert() is complicated enough. It will be great to rework this code and to add comments with reasonable explanation of the essence of modification. It’s not so easy to follow how moving is related to read the key operation. What do you think? Thanks, Slava. > hfs_brec_update_parent(fd); > } > > -- > 2.43.0 > >
On Tue, 6 Feb 2024 15:05:23 +0300, Viacheslav Dubeyko <slava@dubeyko.com> wrote: > > In hfs_brec_insert(), if data has not been moved to "data_off + size", the size > > should not be added when reading search_key from node->page. > > > > Reported-and-tested-by: syzbot+57028366b9825d8e8ad0@syzkaller.appspotmail.com > > Signed-off-by: Edward Adam Davis <eadavis@qq.com> > > --- > > fs/hfsplus/brec.c | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/fs/hfsplus/brec.c b/fs/hfsplus/brec.c > > index 1918544a7871..9e0e0c1f15a5 100644 > > --- a/fs/hfsplus/brec.c > > +++ b/fs/hfsplus/brec.c > > @@ -138,7 +138,8 @@ int hfs_brec_insert(struct hfs_find_data *fd, void *entry, int entry_len) > > * at the start of the node and it is not the new node > > */ > > if (!rec && new_node != node) { > > - hfs_bnode_read_key(node, fd->search_key, data_off + size); > > As far as I can see, likewise pattern 'data_off + size’ is used multiple times in hfs_brec_insert(). > It’s real source of potential bugs, for my taste. Could we introduce a special variable (like offset) > that can keep calculated value? The code after "skip:" only adds size at this point, so currently there is no need to add variables for separate management. > > > + hfs_bnode_read_key(node, fd->search_key, data_off + > > + (idx_rec_off == data_rec_off ? 0 : size)); > > I believe the code of hfs_brec_insert() is complicated enough. > It will be great to rework this code and to add comments with > reasonable explanation of the essence of modification. It’s not so easy > to follow how moving is related to read the key operation. As the case may be, other code is just complex but no issues have been reported. It is not recommended to make unfounded optimizations. > > What do you think? Thanks, Edward.
diff --git a/fs/hfsplus/brec.c b/fs/hfsplus/brec.c index 1918544a7871..9e0e0c1f15a5 100644 --- a/fs/hfsplus/brec.c +++ b/fs/hfsplus/brec.c @@ -138,7 +138,8 @@ int hfs_brec_insert(struct hfs_find_data *fd, void *entry, int entry_len) * at the start of the node and it is not the new node */ if (!rec && new_node != node) { - hfs_bnode_read_key(node, fd->search_key, data_off + size); + hfs_bnode_read_key(node, fd->search_key, data_off + + (idx_rec_off == data_rec_off ? 0 : size)); hfs_brec_update_parent(fd); }