From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1owN7l-0002RT-3r for mharc-grub-devel@gnu.org; Sat, 19 Nov 2022 07:39:10 -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 1owN7i-0002RJ-JF for grub-devel@gnu.org; Sat, 19 Nov 2022 07:39:06 -0500 Received: from mout.gmx.net ([212.227.17.22]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1owN7g-00028r-Fr for grub-devel@gnu.org; Sat, 19 Nov 2022 07:39:06 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=s31663417; t=1668861524; bh=PP/zZbt/KIfU0kra1Kf0any6dpxkGYwulRPUwpnubZE=; h=X-UI-Sender-Class:Date:From:To:Subject:Cc; b=B9vAxqw25yuAygt3IXxYbMb75uw4BDbt5EQzRBqb6oGKwmsURig2d7efFPNGBSKWE u467wkOSBRpmNa2BBB3kci8O89gslpPVzQnEyypohY+R72z9FhgTw29iNLcxgvt/C5 aqjewl28juBkvr4QEGa3qEimayfeOgOgFHSs0nmtjAZgIBGvEMqmiIIh+0OMJeqlAF tU0yN7o8d4jDNO8N0TN2SbqauByu4n3/U1Rg/WBHgeM1lpy6hSenbId4VKMsDTV3Pd z1r2/6LtrBBxi/1nwu2pKv7Wt7ec2BBQW2hp2XcrVpB6CyL948G7mHNKnVeFYmkkR2 Mz9Jlh5pluG/w== 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 1MkYbu-1pM6Qs2xmo-00m1pp; Sat, 19 Nov 2022 13:38:44 +0100 Date: Sat, 19 Nov 2022 13:38:17 +0100 From: "Thomas Schmitt" To: grub-devel@gnu.org Subject: Possible memory fault in fs/iso9660 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Cc: fengtao40@huawei.com Message-Id: <3122440041805325292@scdbackup.webframe.org> X-Provags-ID: V03:K1:ro+r0BrILsl2TrKh3fX5InhZD816vGK8bRoUTJD8jCrS+0VeWrQ phSpctAWWd5XR9JPq6dwt2kkB90eDJcWRk60zFXJ+TSfQnlArxHKZ4QwUyXAm1QEhZVWsdW e68q8wSFZqPOucsF4O8DZK2WJwKblRd6Gyz3QyGLLBkEeS86gsuWZezUfdGlXWMhFJV6MgL 2G6XZucJZ6WQ641CVQLAg== UI-OutboundReport: notjunk:1;M01:P0:0V502u7fcPk=;nGG26Im0nGeTKLGi9MH+yy0FsB2 eAgaYT23e1XeMmCtRbW9LJrpFdV5rOR2v+1OYESSBdmr1XGtoQUfAwK7FC3A5GQF9b7A2Y3vO j3Gcx52s/jZhJ/6u+1MKbF4C+j2XSDjdNpjefhqRcUtNw+PxVTRxXrRS9kFynYj5mxuW8XwN7 MfrzdmgBniiLra4c7PPAYWaLXADh5T/tWKQyrZyXiMlDLUji9735Sfmzp+ka2vXRHMS1q/5dH S7SStkHuLF/jK1mObiDadQ1btoFHM0e6FFmZXevCYWjo5DlCKsyT81lqu3/NGBhTdUdZY67j6 PCbOVUDWFMKNwqNB4P3Nf0cmeH1lBWN0wQSmaBHr8/yWDbjQW4kpTH6ZpNG5T3vRn13qfZF36 R1wZJbyW+YcMGrMnpt/0rjT8oud6GgoHj6baA9SHCohNgiZ7hvLjfMkZjQssLQEuTXyAqhWyp iUdBFcrD+EYwh/eX0SxxuG1Y2V8ghEOSJgTdD1X7f9r14tCwdRI8ZFPqPAFpfGv/f6EKG6tXz gq0ytXL0F+qdKquNL3Iq7FkHwF8o1iDhYjXT475nNxuExCTlBMAabh0m8CqwEog2np4FSWyGs zHgEsl3pIvp177Vpz4QGW6odbk2O1LIxt7hu6eEha/6aEIGMM94q+4xmN0AxtYKhKWe7bTgTq KxLGNLAv/AcaTfdc/rK9Dnp0LOatm/b+vAZfgFdJztBGVaB6azYFjYDxiHpdquNRY08ndQ1WP WzEE/EzHx3oMVsdPBfoe/rIbQeEfni7xgTq6I87v4Frn0PWdCP0dduljFXWCiIKTZNt640rS4 yeib2AqowAlQI7PjAoHKcKaqASCl5pFLnJWqzS0njbe67YcGLlubiL3ivWz+f0+/hSIlXfpgZ vYjspYd9tvqX3zhH5YXr4nlXFJDOpS9209OGuf++aZkX6mrjd1HoiUMSZ6xfjwMlA0jZkJ2f3 oq4R0meVXjT/DB9w6iBbDYZyGHk= Received-SPF: pass client-ip=212.227.17.22; 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: Sat, 19 Nov 2022 12:39:08 -0000 Hi, (Cc-ing t.feng in the hope that this issue can become part of the code review.) While reviewing "[PATCH 7/9]" by t.feng, i wonder whether there is a bug in grub_iso9660_susp_iterate() in regard to the end of the SUSP data: for (entry =3D (struct grub_iso9660_susp_entry *) sua; (char *) entry < = (char *) sua + sua_size - 1 && entry->len > 0; entry =3D (struct grub_iso9660_susp_entry *) ((char *) entry + entry->len)) { I think the loop end condition should use 4 rather than 1: (char *) entry < (char *) sua + sua_size - 4 && entry->len > 0 The entry struct has at least 4 bytes: struct grub_iso9660_susp_entry { grub_uint8_t sig[2]; grub_uint8_t len; grub_uint8_t version; grub_uint8_t data[0]; } GRUB_PACKED; Especially the expression entry->len > 0 reads beyond the end of the allocated buffer sua if entry >=3D sua + sua_size - 3 It does not look as if there are guard rails installed yet: The size of the allocated space (parameter sua_size) is determined by the callers of grub_iso9660_susp_iterate from struct grub_iso9660_dir objects, which obviously represent ISO 9660 directory entry bytes as read from the filesystem. =2D-----------------------------------------------------------------------= --- So the producer of the ISO filesystem can create in GRUB the impression of trailing bytes which form no valid SUSP entry. This may even happen in good faith because a ISO 9660 System Use field may hold data which are not under control of the SUSP protocol. There is a "ST" entry specified which explcitely ends the range of SUSP. But the SUSP specs, both 1.10 and 1.12, mention that a System Use field or a Continuation area may end without ST entry with up to 3 remaining bytes which shall be ignored. From SUSP 1.12: If the remaining allocated space following the last recorded System Use Entry in a System Use field or Continuation Area is less than four bytes long, it cannot contain a System Use Entry and shall be ignored. Otherwise an "ST" System Use Entry (see section 5.4) shall be the last System Use Entry recorded in a System Use field or Continuation Area. Neither mkisofs/genisominage nor libisofs write any ST entries. At least for libisofs i can state that there is no trailing non-SUSP data announced by the size of the directory entry or the Continuation Area. Have a nice day :) Thomas