From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1pIBMb-0003fS-Lh for mharc-grub-devel@gnu.org; Wed, 18 Jan 2023 11:32:37 -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 1pIBMQ-0003co-Vm for grub-devel@gnu.org; Wed, 18 Jan 2023 11:32:32 -0500 Received: from mout.gmx.net ([212.227.15.18]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pIBMN-0007VJ-7C for grub-devel@gnu.org; Wed, 18 Jan 2023 11:32:25 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=s31663417; t=1674059530; bh=tBiB0GxUXc7evVpMWAOyJs5debAjysiyCMXQRKby0Co=; h=X-UI-Sender-Class:Date:From:To:Subject:Cc:References:In-Reply-To; b=htv9ie/DRPqV9j8b8fCoebR4pQ7yT28ACS65ZQWw574HzBQ5ZZXWxlwiXDTHtnM1i RuCv3VV/sLK/L1x7hsJUsJqNfk/ODJkWtq9DvFlAczBPyMaBNZGSkawPBxPFcmWjXX pIwMB9o+lAzQY1AH+iHh/x1F2y/T18DvCk1niEoM5gg5555lGsRx62ECAIsC5PPOSt Y1+O2Ez+n3GzD3dQbzphHC9V1py5FUe8JEVSRgR7A2xpcTxfVUWaR9kHlNmmHHUxYi raJSwmfr4UIZVEbZOSOI17GLa1CJwCgeq1undXwLNC/ZNfB1UjzMEeCVu9E2b0itBG XuE1uRC/pCdkg== 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 1N4hzZ-1ocLNt07qp-011k34; Wed, 18 Jan 2023 17:32:10 +0100 Date: Wed, 18 Jan 2023 17:31:18 +0100 From: "Thomas Schmitt" To: grub-devel@gnu.org Subject: Re: [PATCH v2 0/5] fs/iso9660: Fix out-of-bounds read 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: In-Reply-To: Message-Id: <129543930331941016732@scdbackup.webframe.org> X-Provags-ID: V03:K1:uNsSH+liM9ZAePUcTraQeqnwwfk6Jgv0PKSQST/99BTlW9y6/dv BgDbw9z1Vyzn7A+me28fpuUkARnkhqZMcNQ1LXWljAeSBiHncw2gHd85z86XpjoyJe4rHFq GWZtRs3K3BTPPkHy9z8XXhlsJTxIlsROZ0BTzJ7YFFaRFsXkZlpZDMoRQYSdr4i3XQYNtOc FVqj56nKKxQna+Im7LH6A== UI-OutboundReport: notjunk:1;M01:P0:phLQl2yzxRI=;UORsPL9P/ntTwsdhtGOYYyych/E IqoDkLjiFuWWi9DthPe5r5CLni7n/EVeywd7144v4kiVoCo2p5uldjYR2ofOfJu6wlBuB8E66 zXnip1RfsuBD1TTOFOUGlWpITTi1G3lV6/iItx1G4/zj86kz3iPLT0MfCkPMeUfhMAFmgH0m6 TyiOePhIsAxorkQe6SwgTCbinHtOwapeE9yhXwPeoYSK2VcXFOF7GiEl4I8fsr1pCywX6TPeI txIZM+fsmhx8G6JDpIihkiqTGSn4sWVp1Dqq5ARQOMXNt5WRwcdJKxfIFaICrWmtLjx84yPz4 xMXuu1EXjiMTbb3dQcdq7GIIFNw+v3yPJ0NzxvBCUtMNgSIJNf0vygaShill4BW89r1T4FuhR WcI+2taVQwjhxqou87TfD5PiZIOkDKfvovi1IPS8nWkeyo5s2cqeU3Qjgs7Z29B/WcHogRNG1 RhIafOUIhrEM4nokM8XO5PSwDiWhqlrma4pOpI3bkqRy9FAFtT6qJ7frrKnDoPPjPHR24Tm97 RJyhmUtbRTOx7Ty7LY6bGOCcS25WddFhBPsPychkapJ85FfKPhL/hkZ1GGJk9WfP/V1j0jTVr pPPGM65QXY2iFq63wPzpORDaZscJjJXLie1929ZEMJLuQ8fPkFnCHMTi6KIr8mOh7gBUqqTAv lIjq297Eejq3XIZSf4bDFpHUK9q9/yMmCmsNSUR6XzPaqHNu6i3PAMaILB2SzB2RXEI4trmIW JNFsf/TXE1I/Q489izPeYHdg11v7YVtS6yDHnNDWEe7iFh6EZmKvoVS9CI8SlRdZ9VE/6l3YZ 1v+cWh69x+99DCeDgTeI42MryaNpHbtMd+t74rvD+mdWkvNh0E9srS3ZagK4An27Z0xFFMSEH AxEFpU+VyNlOB6/2ES4Jm/A6ksiidP233NAYYInT6u644e8+dg1GUenpc0rvr8vxUFIUFlKkM TjTq++5Xsy0G0X803FCIZzGEyyk= Received-SPF: pass client-ip=212.227.15.18; 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: Wed, 18 Jan 2023 16:32:34 -0000 Hi, On Wed, 18 Jan 2023 08:23:53 +0000 Lidong Chen wr= ote: > Thomas also pointed out the issue of the potential endless > loops by CE. Since the sugguested fix requires a bit more > investigation, and as Thomas pointed out that it should be > handled in a separate patch, the fix is not included in this > this v2 patches set. Because I am not an expert, it would > be better that someone else can work on it. For the background > info and the comments, please see this email. The bottom half > of the email addressed the endless loop issue: > > https://www.mail-archive.com/grub-devel@gnu.org/msg35785.html I had a look at Linux fs/isofs/rock.c about the handling of CE loops. It works with a hop counter like my current untested proposal for GRUB, which i made in above mail. But Linux is very restrictive: /* Maximum number of Rock Ridge continuation entries */ #define RR_MAX_CE_ENTRIES 32 ... ret =3D -EIO; if (++rs->cont_loops >=3D RR_MAX_CE_ENTRIES) goto out; So probably my proposed limit of a million is just oversized. But i think that 32 would be too low. The Linux limit is bad news for people who want to put larger data blobs into SUSP controlled blocks, because the size of a continuation area is also restricted by Linux to a single block of 2048 bytes. The EIO in case of too much CE entries does not show up in the system log or on the terminal. Just the file is not listed and not accessible: $ wc /mnt/iso/x wc: /mnt/iso/x: No such file or directory I understand from source code and experiments that the actual maximum number of CE hops in Linux is 31 rather than 32. libisofs and xorriso are in the process of getting an adjustable curb to prevent the production of ISO filesystems with files which would not show up in Linux. I decided for 100,000 hops as hard limit but set the default to 31. (SUSP prescribes that entries of unknown type be "ignored and skipped", which Linux normally does fine. Here it could do better.) Have a nice day :) Thomas