Received: by 2002:a05:7412:b101:b0:e2:908c:2ebd with SMTP id az1csp3340348rdb; Thu, 16 Nov 2023 07:07:08 -0800 (PST) X-Google-Smtp-Source: AGHT+IFUFMwTEynfo54ipeHVrjNaZWVIWCLDYYQEWp5WufKoki5Oe8GHag8O5ZpK7Y38ejX7Jft/ X-Received: by 2002:a17:90a:1951:b0:27d:669e:5a10 with SMTP id 17-20020a17090a195100b0027d669e5a10mr15636239pjh.13.1700147228104; Thu, 16 Nov 2023 07:07:08 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1700147228; cv=none; d=google.com; s=arc-20160816; b=HtGBJMG1xXcNZfXE3jXgP5gwyAfhBmkTyTx0QlZ3mh6W6lWxYEeNxUB9V3uC/VE798 918OzADzjBdg8x1vE2TqkbCJ8LfMv+I7AkSPr/CQCP0r8rAs/72svBTFFt97TkwP6L5r 4lwIllhpkauRuD1zDDtBgTQum7P+RF54fFf0m2A+N0khUmMg7wx7+9vUrTYNoMotyeOC KUJqRZ8AyIJri6d8d/j9bQKCkvL0xwZZgkixTL1lOBCZEMPUorFoc6tL3b8TYpZYx01m IXfFtGgkWQEHhJHqmJoJztejEBQaxNa1G0VCYOWrio5xu7pXqIuZ4I2hu1JCYbaRZm/c PPFA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=BQPhdaYQ1sjxlRQ6PKk/9E+L/5AS7twRpFtjZJR+opk=; fh=4Oi+lW6qVttL6RHf8mRYt/qy0SflVNOXGyAJtkJXSC0=; b=oQrc3Ll/74xmolDpejSFeiEcIWkbZjVHcjvJlijyPtCtHejUOnhBkSpq3MfBsk47Fz G9nFbe07BA87/FZp7sseVIgpdanhSjlIQNz8k+lT0rGo7ETUyaCPDOOMJWZ8QLu+HJzC eKQhhpkg9D9qbjaVP3TL0SPUHushMBRzr8xxq7BxfUnhOhkkx6yO6pFvhlmxpzB0dCkL BfzFSHMsYLnb/xUJqPyazTrGrH/Cuf/Jej0+muWUZu1NSxniQaGarowK3G+q0B+SB2K4 yLy3l0SwL7tbrwgqj0DE7ukCQFnaF4olUBoCNL5ym4P6B4ugvbVXuUeQqltxZ1yfGJdA Vz5Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from groat.vger.email (groat.vger.email. [23.128.96.35]) by mx.google.com with ESMTPS id o18-20020a17090ac71200b0027916d248bbsi2225800pjt.162.2023.11.16.07.06.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 16 Nov 2023 07:07:08 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) client-ip=23.128.96.35; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by groat.vger.email (Postfix) with ESMTP id 5B7C680A0E1B; Thu, 16 Nov 2023 07:06:51 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at groat.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345385AbjKPPGj (ORCPT + 99 others); Thu, 16 Nov 2023 10:06:39 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57038 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345373AbjKPPGi (ORCPT ); Thu, 16 Nov 2023 10:06:38 -0500 Received: from p3plwbeout17-05.prod.phx3.secureserver.net (p3plsmtp17-05-2.prod.phx3.secureserver.net [173.201.193.170]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7AE9519D for ; Thu, 16 Nov 2023 07:06:34 -0800 (PST) Received: from mailex.mailcore.me ([94.136.40.141]) by :WBEOUT: with ESMTP id 3dwtrfFAhvZgf3dwurp2ES; Thu, 16 Nov 2023 08:06:32 -0700 X-CMAE-Analysis: v=2.4 cv=a8D1SWeF c=1 sm=1 tr=0 ts=65562ffa a=bheWAUFm1xGnSTQFbH9Kqg==:117 a=84ok6UeoqCVsigPHarzEiQ==:17 a=ggZhUymU-5wA:10 a=BNY50KLci1gA:10 a=VwQbUJbxAAAA:8 a=1XWaLZrsAAAA:8 a=FXvPX3liAAAA:8 a=PL5bajTykxBvxVk0eB4A:9 a=AjGcO6oz07-iQ99wixmX:22 a=UObqyxdv-6Yh2QiB9mM_:22 X-SECURESERVER-ACCT: phillip@squashfs.org.uk X-SID: 3dwtrfFAhvZgf Received: from 82-69-79-175.dsl.in-addr.zen.co.uk ([82.69.79.175] helo=phoenix.fritz.box) by smtp04.mailcore.me with esmtpa (Exim 4.94.2) (envelope-from ) id 1r3dwt-00087x-95; Thu, 16 Nov 2023 15:06:31 +0000 From: Phillip Lougher To: eadavis@qq.com Cc: akpm@linux-foundation.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, phillip@squashfs.org.uk, squashfs-devel@lists.sourceforge.net, syzbot+604424eb051c2f696163@syzkaller.appspotmail.com, syzkaller-bugs@googlegroups.com Subject: Re: [PATCH] squashfs: fix oob in squashfs_readahead Date: Thu, 16 Nov 2023 15:14:24 +0000 Message-Id: <20231116151424.23597-1-phillip@squashfs.org.uk> X-Mailer: git-send-email 2.35.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Mailcore-Auth: 439999529 X-Mailcore-Domain: 1394945 X-123-reg-Authenticated: phillip@squashfs.org.uk X-Originating-IP: 82.69.79.175 X-CMAE-Envelope: MS4xfB5rOlsiGop8HRtnu0KyA/F2yLCMHDiUDEG5UIulqyatT99bi2VOXEs8vuIFxZy253GAgcp2y6YI8YCPnIU7tKO0bluGutBeM0RAaUz1hSQhQrNkii0Q d89UWD78/d01l+wQckM+6EduHaJAnZiE19rjcFOF6yAniL65Zx3BIlE8YjiWcgGSpOYPKqEkYlEV9eqChuZWkOZIs9zgobyBBvE5hFZo4KJzcGrhuPIg8G30 6+cV38CbR9MEL0WDqPJAHw== X-Spam-Status: No, score=-0.8 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on groat.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (groat.vger.email [0.0.0.0]); Thu, 16 Nov 2023 07:06:51 -0800 (PST) > [Bug] > path_openat() called open_last_lookups() before calling do_open() and > open_last_lookups() will eventually call squashfs_read_inode() to set > inode->i_size, but before setting i_size, it is necessary to obtain file_size > from the disk. > > However, during the value retrieval process, the length of the value retrieved > from the disk was greater than output->length, resulting(-EIO) in the failure of > squashfs_read_data(), further leading to i_size has not been initialized, > i.e. its value is 0. > NACK This analysis is completely *wrong*. First, if there was I/O error reading the inode it would never be created, and squasfs_readahead() would never be called on it, because it will never exist. Second i_size isn't unintialised and it isn't 0 in value. Where you got this bogus information from is because in your test patches, i.e. https://lore.kernel.org/all/000000000000bb74b9060a14717c@google.com/ You have + if (!file_end) { + printk("i:%p, is:%d, %s\n", inode, i_size_read(inode), __func__); + res = -EINVAL; + goto out; + } + You have used %d, and the result of i_size_read(inode) overflows, giving the bogus 0 value. The actual value is 1407374883553280, or 0x5000000000000, which is too big to fit into an unsigned int. > This resulted in the failure of squashfs_read_data(), where "SQUASHFS error: > Failed to read block 0x6fc: -5" was output in the syz log. > This also resulted in the failure of squashfs_cache_get(), outputting "SQUASHFS > error: Unable to read metadata cache entry [6fa]" in the syz log. > NO, *that* is caused by the failure to read some other inodes which as a result are correctly not created. Nothing to do with the oops here. > [Fix] > Before performing a read ahead operation in squashfs_read_folio() and > squashfs_readahead(), check if i_size is not 0 before continuing. > A third NO, it is only 0 because the variable overflowed. Additionally, let's look at your "fix" here. > @@ -461,6 +461,11 @@ static int squashfs_read_folio(struct file *file, struct folio *folio) > TRACE("Entered squashfs_readpage, page index %lx, start block %llx\n", > page->index, squashfs_i(inode)->start); > > + if (!file_end) { > + res = -EINVAL; > + goto out; > + } > + file_end is computed by int file_end = i_size_read(inode) >> msblk->block_log; So your "fix" will reject *any* file less than msblk->block_log in size as invalid, including perfectly valid zero size files (empty files are valid too). I already identified the cause and send a fix patch here: https://lore.kernel.org/all/20231113160901.6444-1-phillip@squashfs.org.uk/ NACK Phillip