Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp2874980rwb; Wed, 30 Nov 2022 12:06:11 -0800 (PST) X-Google-Smtp-Source: AA0mqf7acGez6cECpGe/jHwbiEmft0eGbAFaZ2Ra8R28UIIhvXDWZPzxOg7hsKEgr8Tk1cPH3Ldh X-Received: by 2002:a63:e74a:0:b0:478:42f:5a3d with SMTP id j10-20020a63e74a000000b00478042f5a3dmr18576332pgk.3.1669838771217; Wed, 30 Nov 2022 12:06:11 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669838771; cv=none; d=google.com; s=arc-20160816; b=RFwe94WsdOHl8rKvrfMB2kUzkzOj13R9GLOigokxqf/I7nS3nSbsjqGN/aSCRx27Zt wWpuSPtI6GuZeat96OxCPSmOaMRZpcpMosrwwS9YuGZv0abrEAR+TAmlWnyDWibazyun yEbMUAu92DypGH5eo+kyS8awKmPtD5KjCSuC+HFDkoY91Zq52EcE3NtoKJEDcOUvDq7T S017LLXZV6nEIZHo9U2bQXvMBGdAJ221IsLd/0BrkHFML0t/mlUxWHFi1LrUAAUY5EkH hSnaP/3WrJgoO+qn7Mbj7gbX40LTjuBRdyp6gmeM1Puehf+GRLPj7ljLnNur3AEPgmf2 JC8A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:to:references:message-id :content-transfer-encoding:cc:date:in-reply-to:from:subject :mime-version:dkim-signature; bh=+wo+rpyosrQ5mo9ZKXiEdshfV8pblh1Ox95hEXjzopc=; b=A6XcL/V1Wwl5BvHkLVO6z0B7V/0Z8IeCaE8elB9MujVWDiwZDCrhzvYjB2TvnP/PrA c3wvjEvaW16PLgt+JJ6d1aOdXrSkGvaCtLQCUmYZDYdtE57ktYG6/NiPw+ZywDmaFj3l t7F+nMQ+JFxyqNSc/fpRUPSZQDS5VyTvK45maH5iHufHLbhBPeudNl0PGgq9ka9rTE+O xBB/flPfa3qX2lvcrRCpsviEjUSdGpJYz3xmdQ/9LdcfIb0PXN28KLfON2ATP6dqyze3 sor0ama92eJgf/xx8PKKT5P/38ZqsX4FkW+VRfPffhGF+eugjHW3FIlahq7uyk/7Y9ql ktvg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@dubeyko-com.20210112.gappssmtp.com header.s=20210112 header.b=lN5NZq66; 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 Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id v3-20020a056a00148300b0056de69b0c76si2616950pfu.283.2022.11.30.12.05.59; Wed, 30 Nov 2022 12:06:11 -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; dkim=pass header.i=@dubeyko-com.20210112.gappssmtp.com header.s=20210112 header.b=lN5NZq66; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229668AbiK3TY0 (ORCPT + 83 others); Wed, 30 Nov 2022 14:24:26 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39796 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229708AbiK3TYD (ORCPT ); Wed, 30 Nov 2022 14:24:03 -0500 Received: from mail-oi1-x231.google.com (mail-oi1-x231.google.com [IPv6:2607:f8b0:4864:20::231]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B571855A8C for ; Wed, 30 Nov 2022 11:24:02 -0800 (PST) Received: by mail-oi1-x231.google.com with SMTP id m204so19875689oib.6 for ; Wed, 30 Nov 2022 11:24:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dubeyko-com.20210112.gappssmtp.com; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=+wo+rpyosrQ5mo9ZKXiEdshfV8pblh1Ox95hEXjzopc=; b=lN5NZq66xcfgJmWvkkoUluI350bdxZR00+FKoZxMShq9efk+8Ito/DmHVUAqiIZSj/ HLC5ZS3q8yiIl6OMYtzoomsmFwxjrbaYBHRambc5r56FFvdEvwmVL22/c89sELLl7Wsv dr8jdIMx2/ogKPh0XRRh+VnQwgcBU8+5sSLa4EevsSBWM13Us0E0pyloCjrTAFVx1SOO PnL5OqbegXw5uerTa2r93gI7++ZPnIoahH+NJnzmhXo3rFgNzEvFiAHA2PC2OU8d/yn0 2enDE7G8oj+M8KXNxMRTk5w0UqWrHT5jIqpAGNlKjiww0N9TSA2GYrW8QRgGY7YB6n0+ KCDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=+wo+rpyosrQ5mo9ZKXiEdshfV8pblh1Ox95hEXjzopc=; b=5MmRfKKJ8j/BQ9NeP5jsS6w2kLwKzJtVFel6Gjb2UntD3mNomT/XnsFHGYapF8vJTe fofa/7Xy7W+QDoQRlNULITETH2asrh86me7SEiAhUvtQntPix/wBea6BoQqSMMyFUAi2 9wvT1CUVeZYWpN9BAip11wpsOdvPeZWSsa5JOBfi5v/9n8NGl6mCvjdL8nLtg15ZW4oG N1vf3o+zxnVqMiL6+YEUva+JoxhK9x5Bu/dJIGh/pRaAckr10+DfDOksZmVBjK4uE69F 5cvZmldhIxqUQurTQqjX3ivvAR5dsqDiYBPN2/mOCWo49PgoRfSj4kvmygBOp34JNKXc ixQw== X-Gm-Message-State: ANoB5plHNf2sPxeiHfuDfXJgv9I22yH5zgokJzsJpExRJJswQY1qt+Sy jSUOwkEL3NlltFAWIZiHBKIdpA== X-Received: by 2002:a05:6808:10d6:b0:354:9397:4cc4 with SMTP id s22-20020a05680810d600b0035493974cc4mr21155160ois.147.1669836241968; Wed, 30 Nov 2022 11:24:01 -0800 (PST) Received: from smtpclient.apple (172-125-78-211.lightspeed.sntcca.sbcglobal.net. [172.125.78.211]) by smtp.gmail.com with ESMTPSA id c39-20020a9d27aa000000b00661b019accbsm1283915otb.3.2022.11.30.11.23.59 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 30 Nov 2022 11:24:00 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Subject: Re: [PATCH] hfs: Fix OOB Read in __hfs_brec_find From: Viacheslav Dubeyko In-Reply-To: <20221130065959.2168236-1-zhangpeng362@huawei.com> Date: Wed, 30 Nov 2022 11:23:56 -0800 Cc: "Matthew Wilcox (Oracle)" , Damien Le Moal , Jeff Layton , Ira Weiny , Andrew Morton , Linux FS Devel , LKML , sunnanyong@huawei.com, wangkefeng.wang@huawei.com, syzbot+e836ff7133ac02be825f@syzkaller.appspotmail.com Content-Transfer-Encoding: quoted-printable Message-Id: References: <20221130065959.2168236-1-zhangpeng362@huawei.com> To: Peng Zhang X-Mailer: Apple Mail (2.3696.120.41.1.1) X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_NONE,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 Nov 29, 2022, at 10:59 PM, Peng Zhang = wrote: >=20 > From: ZhangPeng >=20 > Syzbot reported a OOB read bug: >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > BUG: KASAN: slab-out-of-bounds in hfs_strcmp+0x117/0x190 > fs/hfs/string.c:84 > Read of size 1 at addr ffff88807eb62c4e by task kworker/u4:1/11 > CPU: 1 PID: 11 Comm: kworker/u4:1 Not tainted > 6.1.0-rc6-syzkaller-00308-g644e9524388a #0 > Workqueue: writeback wb_workfn (flush-7:0) > 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_strcmp+0x117/0x190 fs/hfs/string.c:84 > __hfs_brec_find+0x213/0x5c0 fs/hfs/bfind.c:75 > hfs_brec_find+0x276/0x520 fs/hfs/bfind.c:138 > hfs_write_inode+0x34c/0xb40 fs/hfs/inode.c:462 > write_inode fs/fs-writeback.c:1440 [inline] >=20 > If the input inode of hfs_write_inode() is incorrect: > struct inode > struct hfs_inode_info > struct hfs_cat_key > struct hfs_name > u8 len # len is greater than HFS_NAMELEN(31) which is the > maximum length of an HFS filename >=20 > OOB read occurred: > hfs_write_inode() > hfs_brec_find() > __hfs_brec_find() > hfs_cat_keycmp() > hfs_strcmp() # OOB read occurred due to len is too large >=20 > Fix this by adding a Check on len in hfs_write_inode() before calling > hfs_brec_find(). >=20 > Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") > Reported-by: syzbot+e836ff7133ac02be825f@syzkaller.appspotmail.com > Signed-off-by: ZhangPeng > --- > fs/hfs/inode.c | 2 ++ > 1 file changed, 2 insertions(+) >=20 > diff --git a/fs/hfs/inode.c b/fs/hfs/inode.c > index c4526f16355d..a0746be3c1de 100644 > --- a/fs/hfs/inode.c > +++ b/fs/hfs/inode.c > @@ -458,6 +458,8 @@ int hfs_write_inode(struct inode *inode, struct = writeback_control *wbc) > /* panic? */ > return -EIO; >=20 > + if (HFS_I(main_inode)->cat_key.CName.len > HFS_NAMELEN) > + return -EIO; If I understood correctly, we have corrupted struct hfs_cat_key = instance. But what is the initial place of this corruption? What function could introduce such corruption? = Maybe, it needs to find a place(s) where we can add some additional check and potentially exclude the = incorrect input into hfs_write_inode()? I think it is not only place where it makes sense to check the = correctness of struct hfs_cat_key instance. Could we introduce a special function that check struct = hfs_cat_key on corrupted state and to use this function to check the state of the key in = functions that operates by keys? Thanks, Slava.=20 > fd.search_key->cat =3D HFS_I(main_inode)->cat_key; > if (hfs_brec_find(&fd)) > /* panic? */ > --=20 > 2.25.1 >=20