grub-devel.gnu.org archive mirror
 help / color / mirror / Atom feed
From: Daniel Kiper <daniel.kiper@oracle.com>
To: grub-devel@gnu.org
Cc: dfirblog@gmail.com
Subject: [SECURITY PATCH 4/6] fs/ntfs: Fix an OOB read when parsing bitmaps for index attributes
Date: Tue,  3 Oct 2023 19:12:26 +0200	[thread overview]
Message-ID: <20231003171228.17251-4-daniel.kiper@oracle.com> (raw)
In-Reply-To: <ZRxK8s4nQV2jBq/9@tomti.i.net-space.pl>

From: Maxim Suhanov <dfirblog@gmail.com>

This fix introduces checks to ensure that bitmaps for directory indices
are never read beyond their actual sizes.

The lack of this check is a minor issue, likely not exploitable in any way.

Reported-by: Maxim Suhanov <dfirblog@gmail.com>
Signed-off-by: Maxim Suhanov <dfirblog@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
---
 grub-core/fs/ntfs.c | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/grub-core/fs/ntfs.c b/grub-core/fs/ntfs.c
index 2d78b96e1..bb70c89fb 100644
--- a/grub-core/fs/ntfs.c
+++ b/grub-core/fs/ntfs.c
@@ -843,6 +843,25 @@ grub_ntfs_iterate_dir (grub_fshelp_node_t dir,
 
 	  if (is_resident)
 	    {
+              if (bitmap_len > (at->mft->data->mft_size << GRUB_NTFS_BLK_SHR))
+		{
+		  grub_error (GRUB_ERR_BAD_FS, "resident bitmap too large");
+		  goto done;
+		}
+
+              if (cur_pos >= at->mft->buf + (at->mft->data->mft_size << GRUB_NTFS_BLK_SHR))
+		{
+		  grub_error (GRUB_ERR_BAD_FS, "resident bitmap out of range");
+		  goto done;
+		}
+
+              if (u16at (cur_pos, 0x14) + u32at (cur_pos, 0x10) >
+		  (grub_addr_t) at->mft->buf + (at->mft->data->mft_size << GRUB_NTFS_BLK_SHR) - (grub_addr_t) cur_pos)
+		{
+		  grub_error (GRUB_ERR_BAD_FS, "resident bitmap out of range");
+		  goto done;
+		}
+
               grub_memcpy (bmp, cur_pos + u16at (cur_pos, 0x14),
                            bitmap_len);
 	    }
-- 
2.11.0


_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

  parent reply	other threads:[~2023-10-03 17:13 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-03 17:10 [SECURITY PATCH 0/6] GRUB2 NTFS driver vulnerabilities - 2023/10/03 Daniel Kiper
2023-10-03 17:12 ` [SECURITY PATCH 1/6] fs/ntfs: Fix an OOB write when parsing the $ATTRIBUTE_LIST attribute for the $MFT file Daniel Kiper
2023-10-03 17:12 ` [SECURITY PATCH 2/6] fs/ntfs: Fix an OOB read when reading data from the resident $DATA attribute Daniel Kiper
2023-10-03 17:12 ` [SECURITY PATCH 3/6] fs/ntfs: Fix an OOB read when parsing directory entries from resident and non-resident index attributes Daniel Kiper
2023-10-03 17:12 ` Daniel Kiper [this message]
2023-10-03 17:12 ` [SECURITY PATCH 5/6] fs/ntfs: Fix an OOB read when parsing a volume label Daniel Kiper
2023-10-03 17:12 ` [SECURITY PATCH 6/6] fs/ntfs: Make code more readable 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=20231003171228.17251-4-daniel.kiper@oracle.com \
    --to=daniel.kiper@oracle.com \
    --cc=dfirblog@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).