Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp3244647rwb; Wed, 30 Nov 2022 17:57:23 -0800 (PST) X-Google-Smtp-Source: AA0mqf7oBc+/L4iuS+e/rPvmF3u7bMJVoFByVaiMT7n4jycztiurAsIUVkml8HMIIb4eUHSvXLqw X-Received: by 2002:a17:906:1713:b0:7a3:fc74:7fb4 with SMTP id c19-20020a170906171300b007a3fc747fb4mr56297117eje.17.1669859843090; Wed, 30 Nov 2022 17:57:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669859843; cv=none; d=google.com; s=arc-20160816; b=UvNUSdNZjJw8ZZNeSVcZ27isAdbmH/BDAVET2xlaQRGaFdEvdglKj5bEKoob86GmNb Aer1lJP8B/KmDWVL1BLXYK3axhNEZsUKiDo4hXEadPuSZ2E2AnJvH2w+gmtBKDmHn9HG 1wRsvWGMalz48DSXzYqHRKPU2bcRDrlLJd1SeJJdD+Xk42LXrlpYVqqAGZJiWdQRFxqM NM1pdBNWYPXYidXfuLkX2RFCl5V80tbCkhIs+3mHQeRFhkXz/qCSP+7i7Rw7gZM9hAk1 4js7+Iqxk6uFbfgnkMjNOADHmhYqLEU4cwpMzrItbfs3rVZiJyx3XhRxBe7yMcwkDxfR 9Pxw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id; bh=uv7PhfTa/U4D4kLZLMEjjtz86VEwc8v7cSk3m0PtgRg=; b=z0oYWtJm9zStdgR6KzMF157IT3Shp4KMQ7CKgqInJ0Pas/sMEyvUT4GKFuN0BFaJ4j 3ku6Qehi/nLHmp/Hiq3JxbC/G6bU05Q2UXVMvhISpZFsw17NZ+Cz7L9yzeryn5kmEhst SKZeg8D+04jYghF/0cPMvowZJvLnYihwqBlOulLfhWVCkDrhyY7mipxRDYz/O4lDqgKX jfmqBgXXvCBGHp9wyIGt8dk6GNhAc3+JepPHa0dkF5I5cCW6y+UVOTP/L7XzHSyZNz+f yGTxrs80t070Zd/I223FaS1Xgy+KvCWddRxD5O8Z/5RXNkNFZJpy2W7bUD0cW42PgPpM IzPw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id a17-20020a17090682d100b007ae26c33a6fsi1888656ejy.685.2022.11.30.17.57.03; Wed, 30 Nov 2022 17:57:23 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229627AbiLAByU (ORCPT + 82 others); Wed, 30 Nov 2022 20:54:20 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59556 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229916AbiLAByH (ORCPT ); Wed, 30 Nov 2022 20:54:07 -0500 Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1F91E9AE23; Wed, 30 Nov 2022 17:54:06 -0800 (PST) Received: from dggemv711-chm.china.huawei.com (unknown [172.30.72.55]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4NMzcW6qsYzHwJB; Thu, 1 Dec 2022 09:53:15 +0800 (CST) Received: from kwepemm600020.china.huawei.com (7.193.23.147) by dggemv711-chm.china.huawei.com (10.1.198.66) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Thu, 1 Dec 2022 09:53:49 +0800 Received: from [10.174.179.160] (10.174.179.160) by kwepemm600020.china.huawei.com (7.193.23.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Thu, 1 Dec 2022 09:53:48 +0800 Message-ID: <2ca8a20b-047d-bae1-5a01-0892be4d7e7d@huawei.com> Date: Thu, 1 Dec 2022 09:53:48 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.5.0 Subject: Re: [PATCH] hfs: Fix OOB Write in hfs_asc2mac Content-Language: en-US To: Viacheslav Dubeyko CC: , , Linux FS Devel , LKML , , , References: <20221126043612.853428-1-zhangpeng362@huawei.com> <9F97B7A6-9E20-4D70-BA79-8301D80DF9DB@dubeyko.com> <8e298cc0-27b9-a61a-48cc-64a9186048c8@huawei.com> <481BF13E-8CEA-48B4-A29B-0BDE4CAABAF9@dubeyko.com> From: "zhangpeng (AS)" In-Reply-To: <481BF13E-8CEA-48B4-A29B-0BDE4CAABAF9@dubeyko.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.174.179.160] X-ClientProxiedBy: dggems706-chm.china.huawei.com (10.3.19.183) To kwepemm600020.china.huawei.com (7.193.23.147) X-CFilter-Loop: Reflected X-Spam-Status: No, score=-4.5 required=5.0 tests=BAYES_00,NICE_REPLY_A, RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2022/11/30 3:08, Viacheslav Dubeyko wrote: >> On Nov 28, 2022, at 6:23 PM, zhangpeng (AS) wrote: >> >> On 2022/11/29 3:29, Viacheslav Dubeyko wrote: >>>> On Nov 25, 2022, at 8:36 PM, Peng Zhang wrote: >>>> >>>> From: ZhangPeng >>>> >>>> Syzbot reported a OOB Write bug: >>>> >>>> loop0: detected capacity change from 0 to 64 >>>> ================================================================== >>>> BUG: KASAN: slab-out-of-bounds in hfs_asc2mac+0x467/0x9a0 >>>> fs/hfs/trans.c:133 >>>> Write of size 1 at addr ffff88801848314e by task syz-executor391/3632 >>>> >>>> Call Trace: >>>> >>>> __dump_stack lib/dump_stack.c:88 [inline] >>>> dump_stack_lvl+0x1b1/0x28e lib/dump_stack.c:106 >>>> print_address_description+0x74/0x340 mm/kasan/report.c:284 >>>> print_report+0x107/0x1f0 mm/kasan/report.c:395 >>>> kasan_report+0xcd/0x100 mm/kasan/report.c:495 >>>> hfs_asc2mac+0x467/0x9a0 fs/hfs/trans.c:133 >>>> hfs_cat_build_key+0x92/0x170 fs/hfs/catalog.c:28 >>>> hfs_lookup+0x1ab/0x2c0 fs/hfs/dir.c:31 >>>> lookup_open fs/namei.c:3391 [inline] >>>> open_last_lookups fs/namei.c:3481 [inline] >>>> path_openat+0x10e6/0x2df0 fs/namei.c:3710 >>>> do_filp_open+0x264/0x4f0 fs/namei.c:3740 >>>> >>>> If in->len is much larger than HFS_NAMELEN(31) which is the maximum >>>> length of an HFS filename, a OOB Write could occur in hfs_asc2mac(). In >>>> that case, when the dst reaches the boundary, the srclen is still >>>> greater than 0, which causes a OOB Write. >>>> Fix this by adding a Check on dstlen before Writing to dst address. >>>> >>>> Fixes: 328b92278650 ("[PATCH] hfs: NLS support") >>>> Reported-by: syzbot+dc3b1cf9111ab5fe98e7@syzkaller.appspotmail.com >>>> Signed-off-by: ZhangPeng >>>> --- >>>> fs/hfs/trans.c | 2 ++ >>>> 1 file changed, 2 insertions(+) >>>> >>>> diff --git a/fs/hfs/trans.c b/fs/hfs/trans.c >>>> index 39f5e343bf4d..886158db07b3 100644 >>>> --- a/fs/hfs/trans.c >>>> +++ b/fs/hfs/trans.c >>>> @@ -130,6 +130,8 @@ void hfs_asc2mac(struct super_block *sb, struct hfs_name *out, const struct qstr >>>> dst += size; >>>> dstlen -= size; >>>> } else { >>>> + if (dstlen == 0) >>>> + goto out; >>> Maybe, it makes sense to use dstlen instead of srclen in while()? >>> >>> We have now: >>> >>> while (srclen > 0) { >>> >>> } else { >>> >>> } >>> >>> We can use instead: >>> >>> while (dstlen > 0) { >>> >>> } else { >>> >>> } >>> >>> Will it fix the issue? >>> >>> Thanks, >>> Slava. >> Thank you for your help. >> >> After testing, it fix the issue. >> Would it be better to add dstlen > 0 instead of replacing srclen > 0 with dstlen > 0? >> Because there may be dstlen > 0 and srclen <= 0. >> >> we can use: >> >> while (srclen > 0 && dstlen > 0) { >> >> } else { >> >> } >> > Looks good to me. Can I put you down as a Reviewed-by or Suggested-by? Thanks, Zhang Peng > Thanks, > Slava. > >> Thanks, >> Zhang Peng >> >>>> *dst++ = ch > 0xff ? '?' : ch; >>>> dstlen--; >>>> } >>>> -- >>>> 2.25.1