From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1oyDyY-0000ec-Ni for mharc-grub-devel@gnu.org; Thu, 24 Nov 2022 10:17:19 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oyDyO-0000WL-Rv for grub-devel@gnu.org; Thu, 24 Nov 2022 10:17:10 -0500 Received: from mout.gmx.net ([212.227.15.19]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oyDyM-0004rX-PR for grub-devel@gnu.org; Thu, 24 Nov 2022 10:17:08 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=s31663417; t=1669303011; bh=yRgCirj1SeDhj93T66FMDGiceyKiCLwMeo1zJALRfxs=; h=X-UI-Sender-Class:Date:From:To:Subject:Cc:References:In-Reply-To; b=uZ6fG4K/aAJ7wrHcphTiNsiy3FeHP5Bt9rgzSj2BDOhcChFJLbpZE2pqUiV145+id wbg04nf2nkQkQW15hEQPE24U0GUjJvaGf4WqUQ1tcHo/daO6NHbZ7aBnU72BQtftoR EiNpHUsIRs0DzYtEgH+93BsntItQ4cvyPIlS0goU6spsyNszBRQqldOoTwNSbCaggN nKV4EO013IoXG9tHot/HZdXB5/1wvb1YRUvpnMIeTIUl16cKUT/0U97g3DM0UOAa16 33B1VzBzb0fdQGwdw3RGojrubzFKhJ0RkDbcZDzRKgzKIT1OebLkNokv7TWkk2rOlx Dn1KtoTxiSpTg== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from scdbackup.webframe.org ([84.179.236.73]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MybKp-1p7nF02XxV-00yxJf; Thu, 24 Nov 2022 16:16:51 +0100 Date: Thu, 24 Nov 2022 16:16:37 +0100 From: "Thomas Schmitt" To: grub-devel@gnu.org Subject: Re: Possible memory fault in fs/iso9660 (correction) Content-Type: text/plain; charset="utf-8" Cc: fengtao40@huawei.com References: <20221124131740.mioaqoewv6gnag5i@tomti.i.net-space.pl> In-Reply-To: <20221124131740.mioaqoewv6gnag5i@tomti.i.net-space.pl> Message-Id: <29109400204265589390@scdbackup.webframe.org> X-Provags-ID: V03:K1:7ny8WS6r5qZnFfazD9VdWst0/r+fpBTz5DqPhiNfB4xASA+nA6c A2QzyAy01s+dojre6jnLk77aaJXDZcwFixw5kqnyHKDD5Fvjylz2kD1Ef44q2WQOuI0mk48 mV0KFK+c0a/FZkI5sP/AoWTBx7LGdG0fd3ifRwQp8pFmqSVMmNL1DoOSKWfueEUOhdeB9t2 r+ljyuKn0sjjxBKzgMKRQ== UI-OutboundReport: notjunk:1;M01:P0:/QwVEjYcwPA=;jBCLUPrqd4O5dkllIkLLGqE6ZdU GhFXcwF0JNY9IqPntpFmfKARjIzdxCUbf9E7R6gvCw2M/dG5yi7tlYK8utsFGz+ZTTAfEivs2 /q/NZZQUGfGdRZ3xPCcto7vvnaJpFLCnrPfDVLhV87yfhCz0tQBjBmJaqmTZ22eSSxwEcRrNk 1VqgoHzpuaRbK+bOLFTy0MXMzoVwWlU2oRDNk1pzBrb5J582oziMg3R8S79NpI/9yNmvkyOEh bZtwxzKmmhAYCaDs3P2aFHvP7fBOL7eDfxD9mOrAvYiaM0Rf/8aBYLoSyRxszvAtVNEgsYndE RDlIdYc6Va1GXcTEG/mEiqLNQCkGq5RfTb1HqVqr+YWCH6ycKV4vxzmRw/LqnV20PV+bVe3by DcfTg8sfCt1EA9S0js35Mun5MAOmbXwWHDI7DuQBo4RLrhft4DHwtRr8THQwMHTphye7N0SwG noOL1QEQ6Bv80wO/reRbLcLyCNO/blfkMB7bkJezSDZ6xqh2NogUMKFcvEc/3fXZBnJdUyvbz 2lwaMxeuxrLXJihwPAnuibJ6O7Dt4rlF/nEtF1Jkgqg80qk1IjATpHOu8WagcCNEfU/kwxgTC TIpAO4mrE8j4Bfq2ZF5f2AFhvNO+0Uv2PUixlL0Z4ATy4owhWHgW1t6ZnXM+UsThOb6F5+hae 10LbjoYGPu3RsC0x5WJN699cgXTQjhlfTIUlfDMW74sOXgeFOkFElNDScgvjCgRY8mQt9IbQw L1MWB75TBiNcwyEB7eCMbmA6Dwio/k1qmFjqMu3oE0aGSWkNUodCg6TjOs+IehYUKo9xPF0qZ MLVf8ljAUXVqzDqvwf5aFai69UdyAshX2vBqNUqWdJFHkcCTB9oQZS4gCiTZkXi/SSRzuL0/+ sm0f31HEkRS8YZICwDHO5AH9+a5G3rGulKWkrtPL8jyMG8e3D3DxVmy2HzcwdBI+E6/I8C+in 9G1WGQ== Received-SPF: pass client-ip=212.227.15.19; envelope-from=scdbackup@gmx.net; helo=mout.gmx.net X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2022 15:17:14 -0000 Hi, (Again i Cc t.feng in the hope that the review is not finished yet. :)) Daniel Kiper wrote: > I am not an ISO format expert but your thinking LGTM. So you agree that "3" is really the right number if any remaining bytes fewer than 4 shall be ignored ? (I don't trust myself, although i made an example with finger counting.) > could you send a patch fixing this issue? This should be possible. But how to test ? Normal ISOs made with GNU/Linux will cause (entry == sua + sua_size) at the end of the SUSP data. So provoking the problem and checking whether it is solved will need a hacked ISO. I will think about creating such an ISO by help of xorriso and dd. While exploring the SUSP/RRIP entry types which are interpreted by GRUB, i got to more credulence towards the ISO producer. E.g. in grub-core/fs/iso9660.c line 404 ff. /* The 2nd data byte stored how many bytes are skipped every time to get to the SUA (System Usage Area). */ data->susp_skip = entry->data[2]; This is a memory fault if (sua_size < 7). I see no check between sua = grub_malloc (sua_size); and the read access to entry->data[2]. Another example: grub_iso9660_susp_iterate() calls its parameter hook() without checking that the alleged entry size is within the range of sua_size. The hook() function does not get sua_size to check on its own. In general: How mistrusting should GRUB be towards the bytes in the filesystem ? Have a nice day :) Thomas