Received: by 2002:a05:6359:6284:b0:131:369:b2a3 with SMTP id se4csp5773342rwb; Wed, 9 Aug 2023 08:57:30 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHTcYnDLi0c5uMgCYO+jf0jYCjXrrI5J1AeIhJ8gtDty9Xf75m5gY+zh3x2v0cmJlbBhY6z X-Received: by 2002:a17:906:8a6a:b0:99b:4174:77f6 with SMTP id hy10-20020a1709068a6a00b0099b417477f6mr2092709ejc.33.1691596649876; Wed, 09 Aug 2023 08:57:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1691596649; cv=none; d=google.com; s=arc-20160816; b=NCrWbTFxtvw/MXmB0FPQiAF6hda2noBxkHCwsBxgDKPZVp8MDsrcFQBHkTR0lEouzO cZIGRDYHDKgESYlSiQ6rVpeL1eS3Nzo14QXy3PvL8gIuvFYEFCZ62rcV9g9wSJ24Q39S TjfPz/oOdu5B/rIs0c8ZW7IayQMUkaagueyOwXEvRN1yGMoMDLSbCY2aJfcQPCvToHug r9Z2L68/MCym4PGLyoZWLHxR+IeGcg2HLIJ47b//JT01e2MjZDgeGrCwNFJiF5QWNZIO A8P2klhCAZysgsuUJ9TsP1bXQTaYFVUfEtT6qHWIANXyPK1ZdCOWgkbzHHan6X5xAYoK JDgA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature :dkim-signature; bh=vBSdg5lGWPozZuQqsIRUzfuQJQeSHKdh98LQD8hsqUA=; fh=A2w5Bo5kWXc8kU9d7MSTZh/2rVd+A7i9Q2rLiBdsTr4=; b=O+WcuRVho/OP1d9lFE96qN5lkpHCshXaH1vI0hY8ORjSceOV79hFgE8lg1rqmygTx/ NJ2D7HW+z+3D2WFU9LnKwjJQZfKnsEAvM6fx2iEaALbuJTI7zcyH/ppX45NT2ROpGOuo Ay2Rn0lCTFi5DVhxWQBXdmnTo6krfgS0l8Y/ho13/NVbuv4Uk2qhUgLz5B5vvtgbAfeF EwJmhe2bOlNfKwiNnwF4nzkmt4VzuqqOWGYJBDGZWVT5jSkne3STwMizhz4nDXocVgKa qQqN+kPUbm34wlGieiS7uVjbYTmDlD7R+NUF7hLHrYcpXP7X1Z4yeJDZQIpIKsVsdXoQ zB8Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.cz header.s=susede2_rsa header.b=0QI+gdRB; dkim=neutral (no key) header.i=@suse.cz; 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 h6-20020a170906260600b0099bcf34927fsi9303344ejc.640.2023.08.09.08.57.04; Wed, 09 Aug 2023 08:57:29 -0700 (PDT) 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=@suse.cz header.s=susede2_rsa header.b=0QI+gdRB; dkim=neutral (no key) header.i=@suse.cz; 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 S233101AbjHIPcL (ORCPT + 99 others); Wed, 9 Aug 2023 11:32:11 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57260 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229952AbjHIPcK (ORCPT ); Wed, 9 Aug 2023 11:32:10 -0400 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BD6FA10F6; Wed, 9 Aug 2023 08:32:09 -0700 (PDT) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 75DE01F45E; Wed, 9 Aug 2023 15:32:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1691595128; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=vBSdg5lGWPozZuQqsIRUzfuQJQeSHKdh98LQD8hsqUA=; b=0QI+gdRBhzw7a0KS8OlwzTIibiLKOjQAZnC+j81V4UaWZ5o1FEQZwPI0tU6qf75FIsYxLl v1eVLAw9p/xZvplS1eTe+A3wkX4dKmoIWyp1roxJefHiD3rM7qtFBzy1/W/PcVEpRDCCV+ Lcjf/jfZmJIn7FePH/dWKNAMqZPb3Ko= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1691595128; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=vBSdg5lGWPozZuQqsIRUzfuQJQeSHKdh98LQD8hsqUA=; b=4KPkP26CMTm9vBgsEriOtGdAbcX4UNO7L3/VJEVwjJDk0zXrnxklDskrxYfjQajW0XM7rM VHJp/fEoItWgPNBw== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 67C7A13251; Wed, 9 Aug 2023 15:32:08 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id kHNNGXix02TBSwAAMHmgww (envelope-from ); Wed, 09 Aug 2023 15:32:08 +0000 Received: by quack3.suse.cz (Postfix, from userid 1000) id EA453A0769; Wed, 9 Aug 2023 17:32:07 +0200 (CEST) Date: Wed, 9 Aug 2023 17:32:07 +0200 From: Jan Kara To: Zhang Zhiyu Cc: reiserfs-devel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org Subject: Re: A Discussion Request about a maybe-false-positive of UBSAN: OOB Write in do_journal_end in Kernel 6.5-rc3(with POC) Message-ID: <20230809153207.zokdmoco4lwa5s6b@quack3> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_BLOCKED, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 Hello! On Tue 01-08-23 23:48:59, Zhang Zhiyu wrote: > I found a UBSAN: OOB Write in do_journal_end reported on Linux Kernel > 6.5-rc3 by my modified version of syzkaller on 25 July. I tried to > send an email, but it was rejected by the mail system due to HTML > formatting included in the email. Here is the plain email text: > > The .config, report*, repro.prog, repro.cprog can be found in: > https://drive.google.com/file/d/1GPN68s6mA0Ee3CyK7OSbdBNABuFEzhtv/view?usp=sharing > And the POC can be stably reproduced in the latest kernel (in/after > 6.5-rc3) and the kernel panics. Reproduced screenshot: > https://drive.google.com/file/d/10_4PQHSSwEBCHIMDxjb9EzB6UylRjocP/view?usp=sharing > > After analyzing the root cause, I found it may be a false-positive of > UBSAN. Firstly, the oob behavior happened at > fs/reiserfs/journal.c:4166. When i == 1, it overwrites the > desc->j_realblock[i], which is declared with a size of 1. However, > with a further sight, the desc is wrapped with a b_size=0x1000 when > allocating and i won't be larger than trans_half (smaller than > blocksize), which would prevent the overwriting at line 4166. It seems > a trick of memory access of j_realblock. Yes, j_realblock is in fact a variable length array declared in an ancient way which is likely confusing UBSAN. > But in fs/reiserfs/journal.c:4169, is it possible to manually > construct an extremely long journal link and let i-trans_half > > 0x1000? In this way, commit->j_realblock[i - trans_half] = > cpu_to_le32(cn->bh->b_blocknr); may destroy the memory outside the > block "barrier". And maybe conduct a heap spray? No, it is not possible. Just check how that list is constructed - new members are added to the list in journal_mark_dirty() and there we check there are less than journal->j_trans_max members in the list. And journal->j_trans_max is selected so that the block numbers fit into the descriptor + commit block. > I'm not sure if it's actually an fp, so I haven't patched it yet. I > hope to have some discussion based on my analysis. > > Thanks for your time reading this discussion request. Although I'm a > newbie in kernel security, I am very glad to help to improve the > kernel. Improving kernel security is certainly a worthy goal but I have two notes. Firstly, reiserfs is a deprecated filesystem and it will be removed from the kernel in a not so distant future. So it is not very useful to fuzz it because there are practically no users anymore and no developer is interested in fixing those bugs even if you find some. Secondly, please do a better job of reading the code and checking whether your theory is actually valid before filing a CVE (CVE-2023-4205). That's just adding pointless job for everyone... Thanks! Honza -- Jan Kara SUSE Labs, CR