From: "Thomas Schmitt" <scdbackup@gmx.net>
To: grub-devel@gnu.org
Cc: fengtao40@huawei.com
Subject: Possible memory fault in fs/iso9660
Date: Sat, 19 Nov 2022 13:38:17 +0100 [thread overview]
Message-ID: <3122440041805325292@scdbackup.webframe.org> (raw)
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 = (struct grub_iso9660_susp_entry *) sua; (char *) entry < (char *) sua + sua_size - 1 && entry->len > 0;
entry = (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 >= 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.
---------------------------------------------------------------------------
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
next reply other threads:[~2022-11-19 12:39 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-19 12:38 Thomas Schmitt [this message]
2022-11-19 12:57 ` Possible memory fault in fs/iso9660 (correction) Thomas Schmitt
2022-11-24 13:17 ` Daniel Kiper
2022-11-24 15:16 ` Thomas Schmitt
2022-11-29 9:32 ` Fengtao (fengtao, Euler)
2022-11-29 14:26 ` Daniel Kiper
2022-11-29 19:12 ` Thomas Schmitt
2022-11-29 18:47 ` Thomas Schmitt
2022-12-12 14:32 ` Daniel Kiper
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3122440041805325292@scdbackup.webframe.org \
--to=scdbackup@gmx.net \
--cc=fengtao40@huawei.com \
--cc=grub-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.