From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1p05em-0000bx-3Q for mharc-grub-devel@gnu.org; Tue, 29 Nov 2022 13:48:36 -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 1p05ek-0000bb-9A for grub-devel@gnu.org; Tue, 29 Nov 2022 13:48:34 -0500 Received: from mout.gmx.net ([212.227.17.20]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p05ei-0004xa-Ab for grub-devel@gnu.org; Tue, 29 Nov 2022 13:48:33 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=s31663417; t=1669747642; bh=SUKPPIp+2pIeTSeSUk5NY86eVXkI9+qFXyO2cWjYcxY=; h=X-UI-Sender-Class:Date:From:To:Subject:Cc:References:In-Reply-To; b=Bw99y2EeJPRPXJLs5C14gTT6D3wtTA+mkQuFrmaRMVGXL/aH2kdWf0zXG0ojs6rzw p9wDRl0odxD3kBB6ZqnlmCNYTm4QG3Q63sHtbsGN/IrEz1eE6BxDHrQwbRWfm6m8Ov v54M4B3aPcz9VS7bGTSpb6C9zXfHXn1HRs4aNNvkxJ5K7XtaqIbh1fjDZM5URr1Lt6 0LFtrSR1UYp593j+mf6MNZaxXVbGvjftRZ+dPtSaPMuyRQHtSE55I2fqbiTd9TypFT 1APJNGUek76QcwnldoasVMYW2gWOwED2VfxOjanbF22b/CLdSGmYvra7d+Rc6yunjC XCwQq1HwxNZCA== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from scdbackup.webframe.org ([84.179.236.73]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1M6UZl-1p6xFr16fR-006tqM; Tue, 29 Nov 2022 19:47:22 +0100 Date: Tue, 29 Nov 2022 19:47:22 +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,dkiper@net-space.pl,yanan@huawei.com References: <3ad04de3-aece-fa0a-278f-cf30210722b4@huawei.com> In-Reply-To: <3ad04de3-aece-fa0a-278f-cf30210722b4@huawei.com> Message-Id: <50363882005823433@scdbackup.webframe.org> X-Provags-ID: V03:K1:BN6uukP+GRDRLcQ4EJBJjvE/j3xSEEbONr/4O9dFeWTcbQKZFkC S49Wt5q3bVvB4PK0m0CjDN4GhFvjzJ1Hz06mngCMX5SSID8NIagkuCzHl6M/BuCVJE81dbD HFyDZOt+YC6veBF7lXdge98NDF5FhdjKXi5KIwUf54+WKD49uLrEizM3ZUu/sTQsUPn84zD dxiV09ECaGUzXKT0cfiMg== UI-OutboundReport: notjunk:1;M01:P0:RlWVt1jye/I=;mx7k6Ze+pxE2jfQC+ll4QnENN61 AeerHMqJ4QQjyShXd9qCnjFFLLBnNRIQeML/+Mq2KLBJt2xSOiwFGo8LlNUrSESXSm0JpTLbx qpxAEPtMIm2LmBwWUoJw24IfNYZqADIAzvVfA9vf0wuEi9bTNaZNufJbTF3nopro/3Rqe8P2A gPDp3Qz3xS/EiU8FoFfYMzxY3N8NRHbmw5hV79aOvQnZ02qGp++oQ3v2rQQdKUDed4GukYyrZ 0/lXLE4jTOGFLo/mrRngKd+xa9zy/gobpPuvlLWJSTeCr2xI4M5H54gHORfHjYC45Rh6/PtfN AYZ0KALVRnn7lTKj1KEYKe4EiKIARN04OtyEv0l2p/kZlxFZ7vm2z6H6BG3TLe2Ozmi+GxmyV 2KV3tk2S9zG4bQR3jLASBgKRZjB8abcC6b/86viLhN6KGB+eU1Zigz6qST1nEm0mulhTslfSt AknMWDFAt7h90Twp5C4nlhoRLA20sYIZZO3hk1eP3VcL5gDqVzMqBDjFXF78ZA0ROoxsTOuqB XU2aGPj7UuN9uqhxUZnhWeqB717b7kuvqLcGFIQKYX5+wFLK3CJxMGs/fyEQ1nOMXOFo9OJyo ulwOQKXZxDM+UKFQk99JHNEpk87mBdJb3eCK2aylEZskC7lOz+fAuQf86msigV6L94gwSmd2s cJmLISZLykA4qYLDV+cniZyjN4RZs9j5iV1pAdhwkNA3hyUjISBJQlvg8oE9x7OTzc0KY1J6Q 6G7V/oqA6qIxBl3kAcaxhznAHAe9nPNaZSXMxvadwjUL7r1KSOi7z8+4BztAyCxHsGdwCLfTl Q+guXJVdWrkOSaVnFSn+NGoX91yPFBZkrR8Dj2goz86RtPW9OPRBE/1VrbqfjErovaqDA8YlO t/nVwqQ+hj7rEB7QZyZX1w6Qz/zHMHFSxW33og+tvz/zeST99phf1Gx1z+wGezWifLfpEgxq+ Ds0vRDCGeoqmFKKYhLtlPNbTALU= Received-SPF: pass client-ip=212.227.17.20; 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, RCVD_IN_MSPIKE_H2=-0.001, 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: Tue, 29 Nov 2022 18:48:34 -0000 Hi, Fengtao wrote: > I think: > (char *) entry < (char *) sua + sua_size - 3 && entry->len > 0 > is ok, or: > (char *) entry <= (char *) sua + sua_size - 4 && entry->len > 0 "4" would be overdone. There are SUSP and RRIP entries of length 4, which would be ignored if appearing at the end of the SUSP controlled area. > I am also not familiar with ISO format. I seem to be the last active programmer on that topic. As stated on 24 Nov, i see other potential memory faults in the code of grub-core/fs/iso9660.c if the ISO image contains incorrect SUSP entries. --------------------------------------------------------------------------- I began to hack an ISO image so that it shows non-SUSP data after the SUSP data. (See below.) But now i am having noob problems with grub-fstest. I pulled the source from git://git.savannah.gnu.org/grub on Debian 11 and built it as prescribed in INSTALL. Nevertheless grub-fstest does not show a memory fault with: valgrind ./grub-fstest /dvdbuffer/grub_test_non_susp.iso ls / gdb says that the execution enters grub_iso9660_susp_iterate() Breakpoint 1, 0x000055555557dde4 in grub_iso9660_susp_iterate () but gives no further information, because (No debugging symbols found in ./grub-fstest) Next i tried to insert visible messages into grub_iso9660_susp_iterate(): grub_error (GRUB_ERR_BAD_NUMBER, "grub_iso9660_susp_iterate: called"); ... grub_error (GRUB_ERR_BAD_NUMBER, "grub_iso9660_susp_iterate: before loop"); ... grub_error (GRUB_ERR_BAD_NUMBER, "grub_iso9660_susp_iterate: sua + sua_size - entry = %ld", (long int) ((char *) sua + sua_size - (char *) entry)); I do not see any of them when running with above arguments. So how can i make grub-core/fs/iso9660.c debuggable or let it emit visible messages ? --------------------------------------------------------------------------- The test ISO is made by these commands in bash: # Create an ISO with a playground of SUSP data. echo dummy >dummy_file test -e grub_test_non_susp.iso && rm grub_test_non_susp.iso xorriso \ -xattr on \ -outdev grub_test_non_susp.iso \ -map dummy_file /dummy_file \ -setfattr user.x y /dummy_file -- \ -padding 0 # Search for the AL entry of length 0x0c which holds attribute user.x. # (AL is the entry type of my invention AAIP. It gets ignored by all # readers except xorriso. So it is a good playground for manipulations.) # (There is also another AL entry of size 0x10 in the CE area of the root # directory.) al=$(grep -a -o -b 'AL'$'\x0c'$'\x01' grub_test_non_susp.iso | \ sed -e 's/:/ /' | awk '{print $1}') # Replace length field value 0x0c by 0x0a. # This leaves the last 2 bytes of the AL entry as trailing non-SUSP data # in the System Use field of the directory entry. al_length_offset=$(expr $al + 2) echo $'\x0a' | \ dd of=grub_test_non_susp.iso \ bs=1 count=1 seek="$al_length_offset" conv=notrunc Inspection by a hex dumper shows that the AL entry indeed announces the desired (short) length of 10. --------------------------------------------------------------------------- I also learned by doing and then by reading specs that a padding byte after the System Use data is present if needed to get an even number of bytes as size of the directory record. This could explain the existing "- 1" in GRUB's code. Above ISO is supposed to show 3 non-SUSP bytes at the end of the System Use field: 2 from my dd manipulation, 1 as regular padding. Have a nice day :) Thomas