All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Thomas Schmitt" <scdbackup@gmx.net>
To: grub-devel@gnu.org
Cc: lidong.chen@oracle.com, fengtao40@huawei.com, yanan@huawei.com,
	daniel.kiper@oracle.com, lichenca2005@gmail.com
Subject: Proposal v2: fs/iso9660: Prevent skipping CE or ST at start of continuation area
Date: Fri, 16 Dec 2022 13:57:04 +0100	[thread overview]
Message-ID: <31992389627932343306@scdbackup.webframe.org> (raw)
In-Reply-To: <19021389617225107434@scdbackup.webframe.org>

Hi,

i realize that my previous proposal opens a possibility for regression with
a very bad ISO image.
The danger is in an endless loop by a CE entry which points to itself.
The bug which i want to see fixed currently prevents this special pitfall.

(Other endless loops by CE are possible and not prevented. It's much like
 with symbolic link loops. In the end only a hard limit on the number of
 CE hops would help.)

So i now propose with the same sketch of a commit message, this change
(compiles but was but not tested):
------------------------------------------------------------------------

fs/iso9660: Prevent skipping CE or ST at start of continuation area

If processing of a SUSP CE entry leads to a continuation area which begins
by entry CE or ST, then these entries were skipped without interpretation.
In case of CE this would lead to premature end of processing the SUSP entries
of the file.
In case of ST this could cause following non-SUSP bytes to be interpreted
as SUSP entries.

Signed-off-by: Thomas Schmitt <scdbackup@gmx.net>

--- grub-core/fs/iso9660.c.lidong_chen_patch_2	2022-12-15 11:46:50.654295924 +0100
+++ grub-core/fs/iso9660.c.lidong_chen_patch_2_ce_fix_v2	2022-12-16 13:54:55.654651173 +0100
@@ -336,6 +336,21 @@ grub_iso9660_susp_iterate (grub_fshelp_n
 	    }

 	  entry = (struct grub_iso9660_susp_entry *) sua;
+
+	  /* The hook function will not process CE or ST.
+	     Advancing to the next entry would skip them. */
+	  if (grub_strncmp ((char *) entry->sig, "CE", 2) == 0)
+	    {
+	      ce = (struct grub_iso9660_susp_ce *) entry;
+	      if (ce_block
+		  != grub_le_to_cpu32 (ce->blk) << GRUB_ISO9660_LOG2_BLKSZ
+		  || off != grub_le_to_cpu32 (ce->off))
+		continue;
+	      /* Ending up here indicates an endless loop by self reference.
+	         So skip this bad CE as was done before december 2022. */
+	    }
+	  if (grub_strncmp ((char *) entry->sig, "ST", 2) == 0)
+	    break;
 	}

       if (hook (entry, hook_arg))
------------------------------------------------------------------------


Have a nice day :)

Thomas



  reply	other threads:[~2022-12-16 12:56 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-14 18:55 [PATCH 0/4] fs/iso9660: Fix out-of-bounds read Lidong Chen
2022-12-14 18:55 ` [PATCH 1/4] fs/iso9660: Add check to prevent infinite loop Lidong Chen
2022-12-15 17:52   ` Thomas Schmitt
2022-12-19  8:16     ` Lidong Chen
2022-12-19  9:42       ` Thomas Schmitt
2022-12-14 18:55 ` [PATCH 2/4] fs/iso9660: Prevent read past the end of system use area Lidong Chen
2022-12-15 18:00   ` Thomas Schmitt
2022-12-19  8:39     ` Lidong Chen
2022-12-16  8:54   ` Thomas Schmitt
2022-12-16  9:42   ` Proposal: fs/iso9660: Prevent skipping CE or ST at start of continuation area Thomas Schmitt
2022-12-16 12:57     ` Thomas Schmitt [this message]
2022-12-20 21:08       ` Proposal v2: " Lidong Chen
2023-01-06  5:30       ` Lidong Chen
2023-01-06 16:00         ` Thomas Schmitt
2023-01-09  7:34           ` Lidong Chen
2023-01-09  9:32             ` Thomas Schmitt
2023-01-11 11:54               ` Thomas Schmitt
2023-01-12  5:28                 ` Lidong Chen
2023-01-12  8:45                   ` Thomas Schmitt
2022-12-14 18:55 ` [PATCH 3/4] fs/iso9660: Avoid reading past the entry boundary Lidong Chen
2022-12-15 18:08   ` Thomas Schmitt
2022-12-19  8:42     ` Lidong Chen
2022-12-14 18:55 ` [PATCH 4/4] fs/iso9660: Incorrect check for entry boudary Lidong Chen
2022-12-15 18:20   ` Thomas Schmitt
2022-12-19 21:00     ` Lidong Chen
2022-12-20  9:21       ` Thomas Schmitt
2022-12-14 21:42 ` [PATCH 0/4] fs/iso9660: Fix out-of-bounds read Thomas Schmitt
2022-12-19  8:07   ` Lidong Chen

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=31992389627932343306@scdbackup.webframe.org \
    --to=scdbackup@gmx.net \
    --cc=daniel.kiper@oracle.com \
    --cc=fengtao40@huawei.com \
    --cc=grub-devel@gnu.org \
    --cc=lichenca2005@gmail.com \
    --cc=lidong.chen@oracle.com \
    --cc=yanan@huawei.com \
    /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.