From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1pEoYi-0002fA-5w for mharc-grub-devel@gnu.org; Mon, 09 Jan 2023 04:35:12 -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 1pEoYg-0002dg-UZ for grub-devel@gnu.org; Mon, 09 Jan 2023 04:35:11 -0500 Received: from mout.gmx.net ([212.227.17.21]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pEoYf-0001qf-1K for grub-devel@gnu.org; Mon, 09 Jan 2023 04:35:10 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=s31663417; t=1673256844; bh=KubAEdCT7skDzxbkZpzog58yIRACyOAOOQWP6IMd474=; h=X-UI-Sender-Class:Date:From:To:Subject:Cc:References:In-Reply-To; b=Ag1xSObnEX69mbbqSgfL+SQGFFf+oUZuXBNWgFI51ZcA2v6uUg6v84svSJdiFPTiv 7CcCVHkQ8f7MDhRTbw+2Qgr+Hs/elN/nVkzaQWtdmnYqAJyh2R0y5Yu6wRgSos8XwQ fQiP+m8oqoVRGe6kWEbaf4/bFM7skd5p2nQwHH0VpBBD6o+Knah8ewbaC6vxMjgOnw bJIC/vxVSAypPK76y/NCFVQ1nRvnopRLm3GYHdMkEZG9JTOLeSEXsUdMk5QXUKq8aR XErZh0SL9qMSJJPo9vj9GlaSmBebwmzW7IrkGG1KAnEKJwL8au+07Mc3LevYW1Bz90 Y+uRuZUGz+ubw== 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 1M7b2T-1p90aH2lIL-007zog; Mon, 09 Jan 2023 10:34:04 +0100 Date: Mon, 09 Jan 2023 10:32:48 +0100 From: "Thomas Schmitt" To: grub-devel@gnu.org Subject: Re: Proposal v2: fs/iso9660: Prevent skipping CE or ST at start of continuation area Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Cc: lidong.chen@oracle.com, fengtao40@huawei.com, yanan@huawei.com, daniel.kiper@oracle.com, lichenca2005@gmail.com References: <3E68809E-2A2B-46AF-8F09-40BB0FC42D60@ORACLE.COM> In-Reply-To: <3E68809E-2A2B-46AF-8F09-40BB0FC42D60@ORACLE.COM> Message-Id: <230133879046361020781@scdbackup.webframe.org> X-Provags-ID: V03:K1:J6bTKPLhur764v5gEKKNFB1uHkAOPLulQ6ZpMiUaHBgT7/FINLe UhlHZQkYAwc4pzpmw6zJOfKCpbUC6+b3n/kb2xV1eYCSiR/bMs9E1f9fwsV06NaAk1goGFd mI0CS/s/JJACtUfy62xrh78yOVxkEpfpnWrA5JR2ouTZ/gm6bX3qqd/P9eA/CsHNH11Sgu+ +Xv524TUMTap9Xj/4l/Jg== UI-OutboundReport: notjunk:1;M01:P0:Mlxwh48qrhA=;JjkEOw1NUcgS+8a3rMwCvweADPw cmhqruEybpujpeljbMbkYD+L3Zt8ZgJwWKoTnoHSCszeZHj/KlvPW8Vb2Ee/FFiQsutcNTWSt 5Pu0xY93BGOS0B+l+blGly1L8zb00C5T/9CVyolG+TyfEwwNTjMvd4iJqozWzNFO0YtF6UxDs KE4eOtmLL5mVKDCZ8YXHAfTsGDSwFTuhlzfXz728nsde1TTl0wIvRjYEdUF702mQVgZaJzXcU hSW5Bz5HNe5RA/AyFusjf2bnH3xyS389dNYzUk3He1461wvZqUiFfvUcNqtijfwM+7zRtjIsx vQbUeeNObGuEeC/XId5JkokniaswUnaLTJ2QMGkpU2SGcpO45JjKfPe6awBlzagn2q0IJXIO3 9Uj7s+mVkXjnVyJMtc9Ff8DtYz9viLRvzQxpheUQg2TXrxAPSYoV7Zj9YRx96hhFi+WPi4dKa IxsaigfmJQc+XXnQ0NnAKdrgKXKIGKI8U1FC9P0Ex5TitBWvUzfbg3FtHBc7oQWMCf5KdUa/O ueb9xNbyeg63nQX3FA1FiIdpmURyEy0mA+lNCt0peruK2xv6yjjWZb40Z6F+D0YVEPX6emQhC oKBUv7vihZa/LlgGi8UucMfekCIONOtbav8q9h3M620OpBTlgINqLgIuKrAVvY6bsiOTzVYdo XTJPE3fHsxYsmAczrnBF3+yyyAt9/AsUaGxeq6DKhpAux8kiXYB5P5AROW6Wo+fH+yR57zcjI zXLtIr0JoO3Pe3FWQM38nz06GyPMBtdJ2EJ2Ksh1tH+9UcSxNhcJqYJ3hLSo+ph5kZ8Cj1UDi llf6mV9Uv+jHNCLK5n2YZBOCw2OFs8FRsrwRu4qplXMyiytNcz4QVwsthcOujGb1cC4lRtIzX ukwybpadDTlBaC2Lu9zGeOPjWpzRLZEN0o2QEuCvzsVPXqdMhbx+kaGSfPE/A7wjL3dgbYJO9 GqReuPXw7LaaGHOgMbLWnbOsrHs= Received-SPF: pass client-ip=212.227.17.21; 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: Mon, 09 Jan 2023 09:35:11 -0000 Hi, Lidong Chen wrote: > Thanks for the clarification. I created a new patch for the fix and adde= d > you as the =E2=80=9CSigned-off-by=E2=80=9D. > My question is how to test it. I just sent libisofs into an endless recursion loop. Grrr. For this i created a small ISO with a file which surely needs a CE, change= d its fields so that it points to itself, and attempted to load it by xorris= o. (At least it ends by SIGSEGV on an exhausted stack and does not cycle endlessly.) =2D-----------------------------------------------------------------------= -- ISO creation: # A dummy file as payload echo x >x # 250 fattr characters to surely exceed the size of a directory entry long_string=3D012345678901234567890123456789012345678901234567890123456= 78901234567890123456789012345678901234567890123456789012345678901234567890= 12345678901234567890123456789012345678901234567890123456789012345678901234= 567890123456789012345678901234567890123456789 # Create ISO with the payload file and attached fattr named user.dummy test -e ce_loop.iso && rm ce_loop.iso xorriso -outdev ce_loop.iso \ -xattr on \ -map x /x \ -setfattr user.dummy "$long_string" /x -- \ -padding 0 Next i determined by a hex dumper the location of the only Rock Ridge entry NM and then the location of the next following CE entry (the first CE belongs to the root directory): Byte 102734 decimal =3D 50 * 2048 + 334 =3D LBA 0x32 + Offset 0x014e The size of the continuation area is 270 =3D 0x010e The length of CE is 28 =3D 0x1c So i patched the own address and size of the CE entry into its fields: # The block address (little endian and big endian) echo $'\x32' | dd bs=3D1 seek=3D102738 count=3D1 conv=3Dnotrunc of=3Dce_= loop.iso echo $'\x32' | dd bs=3D1 seek=3D102745 count=3D1 conv=3Dnotrunc of=3Dce_= loop.iso # The byte offset in that block echo $'\x4e'$'\x01' | dd bs=3D1 seek=3D102746 count=3D2 conv=3Dnotrunc o= f=3Dce_loop.iso echo $'\x01'$'\x4e' | dd bs=3D1 seek=3D102752 count=3D2 conv=3Dnotrunc o= f=3Dce_loop.iso # The new size of the CE area is the length of the CE entry echo $'\x1c' | dd bs=3D1 seek=3D102754 count=3D1 conv=3Dnotrunc of=3Dce_= loop.iso echo $'\x1c' | dd bs=3D1 seek=3D102761 count=3D1 conv=3Dnotrunc of=3Dce_= loop.iso # Zeroize the higher valued bytes of the length field dd if=3D/dev/zero bs=3D1 seek=3D102755 count=3D6 conv=3Dnotrunc of=3Dce_= loop.iso This really bad CE entry then looks in the hex dump like: 00019140 : 00 7b 01 09 08 08 1c 00 4e 4d 06 01 00 78 43 = 45 { N M x C = E 102720 : 0 123 1 9 8 8 28 0 78 77 6 1 0 120 67 = 69 00019150 : 1c 01 32 00 00 00 00 00 00 32 4e 01 00 00 00 = 00 2 2 N 102736 : 28 1 50 0 0 0 0 0 0 50 78 1 0 0 0 = 0 00019160 : 01 4e 1c 00 00 00 00 00 00 1c 00 00 00 00 00 = 00 N 102752 : 1 78 28 0 0 0 0 0 0 28 0 0 0 0 0 = 0 (Note: 00019140 is hex, not octal) =2D-----------------------------------------------------------------------= -- I will first try to fix libisofs before i upload this gremlin somewhere. If you want to try in advance, run above shell commands and check whether a hex editor shows the expected bytes afterwards. (xorriso is supposed to be reproducible in respect to sizes and locations. Very old versions might not fulfill that expectation, though.) Have a nice day :) Thomas