grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] minix: avoid mistakenly probing ext2 filesystems


From: Daniel Kiper
Subject: Re: [PATCH] minix: avoid mistakenly probing ext2 filesystems
Date: Mon, 22 Mar 2021 17:18:22 +0100
User-agent: NeoMutt/20170113 (1.7.2)

On Fri, Mar 12, 2021 at 12:05:08PM -0600, Derek Foreman wrote:
> From: Daniel Drake <drake@endlessm.com>
>
> ext2 (and ext3, ext4) filesystems write the number of free inodes to
> location 0x410.
>
> On a minix filesystem, that same location is used for the minix superblock
> magic number.
>
> If the number of free inodes on an ext2 filesystem is equal to any
> of the four minix superblock magic values plus any multiple of 65536,
> grub's minix filesystem code will probe it as a minix filesystem.
>
> In the case of an OS using ext2 as the root filesystem, since there will
> ordinarily be some amount of file creation and deletion on every bootup,
> it effectively means that this situation has a 1:16384 chance of being hit
> on every reboot.
>
> This will cause grub's filesystem probing code to mistakenly identify an
> ext2 filesystem as minix. This can be seen by e.g. "search --label"
> incorrectly indicating that no such ext2 partition with matching label
> exists, whereas in fact it does.
>
> After spotting the rough cause of the issue I was facing here, I borrowed
> much of the diagnosis/explanation from meierfra who found and investigated
> the same issue in util-linux in 2010:
>
> https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/518582
>
> This was fixed in util-linux by having the minix code check for the
> ext2 magic. Do the same here.
>
> Signed-off-by: Daniel Drake <drake@endlessm.com>
> Reviewed-by: Derek Foreman <derek@endlessos.org>

Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>

Daniel

> ---
>
> This bug fix was previously sent to the grub-devel list once before:
>  https://lists.gnu.org/archive/html/grub-devel/2020-05/msg00205.html
> but received no response, so I'm bring it up again.
>
> If my understanding is correct, the bytes in question overlap with the
> "maximum file system size" field in the minix superblock, which will
> never contain the ext2 magic byte pattern, so there shouldn't be any
> unintended side effects.
>
>  grub-core/fs/minix.c | 19 ++++++++++++++++++-
>  1 file changed, 18 insertions(+), 1 deletion(-)
>
> diff --git a/grub-core/fs/minix.c b/grub-core/fs/minix.c
> index d0d08363c..db0a83feb 100644
> --- a/grub-core/fs/minix.c
> +++ b/grub-core/fs/minix.c
> @@ -38,6 +38,8 @@ GRUB_MOD_LICENSE ("GPLv3+");
>  #define GRUB_MINIX_MAGIC_30  0x138F
>  #endif
>
> +#define      EXT2_MAGIC              0xEF53
> +
>  #define GRUB_MINIX_INODE_DIR_BLOCKS  7
>  #define GRUB_MINIX_LOG2_BSIZE        1
>  #define GRUB_MINIX_ROOT_INODE        1
> @@ -466,7 +468,22 @@ grub_minix_find_file (struct grub_minix_data *data, 
> const char *path)
>  static struct grub_minix_data *
>  grub_minix_mount (grub_disk_t disk)
>  {
> -  struct grub_minix_data *data;
> +  struct grub_minix_data *data = NULL;
> +  grub_uint16_t ext2_marker;
> +
> +  grub_disk_read (disk, 1 * 2, 56, sizeof (ext2_marker),
> +                  &ext2_marker);
> +  if (grub_errno)
> +    goto fail;
> +
> +  /* ext2 filesystems can sometimes be mistakenly identified
> +   * as minix, e.g. due to the number of free ext2 inodes being
> +   * written to the same location where the minix superblock
> +   * magic is found.
> +   * Avoid such situations by skipping any filesystems that
> +   * have the ext2 superblock magic. */
> +  if (ext2_marker == grub_cpu_to_le16_compile_time (EXT2_MAGIC))
> +    goto fail;
>
>    data = grub_malloc (sizeof (struct grub_minix_data));
>    if (!data)
> --
> 2.26.2
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel



reply via email to

[Prev in Thread] Current Thread [Next in Thread]