[U-Boot] [PATCH] part_dos: check status flags of partitions

[U-Boot] [PATCH] part_dos: check status flags of partitions

[Daniel Mack]

The current fatload code has a problem together with the way the DOS
partition parser is implemented.

This hit me when I tried to load a file from a USB stick which had no
partition table but a FAT16 directly written to the first sector.

With such an environment, get_partition_info_extended() still finds a
valid partition at the first sector since the 0x55aa magic is valid for
both the MBR and the FAT boot sector.

As a result, part_offset in fs/fat/fat.c is then set to some ridiculous
value and the code searching for the directory entry gets lots in an
endless loop.

The fix is quite simple though - we just need to check the status field
of the partitions more stricly. According to the specs, it may only
contain 0x00 and 0x80. If get_partition_info() fails for this case, the
fatload code falls back to the assumption that there is no partition
table and does the right thing then.

Please consider applying the following patch.

Daniel

[U-Boot] [PATCH] part_dos: check status flags of partitions

[Daniel Mack]

ping?

On Mon, Sep 28, 2009 at 12:04:00PM +0200, Daniel Mack wrote:
> The current fatload code has a problem together with the way the DOS
> partition parser is implemented.
> 
> This hit me when I tried to load a file from a USB stick which had no
> partition table but a FAT16 directly written to the first sector.
> 
> With such an environment, get_partition_info_extended() still finds a
> valid partition at the first sector since the 0x55aa magic is valid for
> both the MBR and the FAT boot sector.
> 
> As a result, part_offset in fs/fat/fat.c is then set to some ridiculous
> value and the code searching for the directory entry gets lots in an
> endless loop.
> 
> The fix is quite simple though - we just need to check the status field
> of the partitions more stricly. According to the specs, it may only
> contain 0x00 and 0x80. If get_partition_info() fails for this case, the
> fatload code falls back to the assumption that there is no partition
> table and does the right thing then.
> 
> Please consider applying the following patch.
> 
> Daniel
> 
> 
> From 381a85bf04adc228cc70e8fa7af899a6dbf07e42 Mon Sep 17 00:00:00 2001
> From: Daniel Mack <daniel@caiaq.de>
> Date: Mon, 28 Sep 2009 11:40:38 +0200
> Subject: [PATCH] part_dos: check status flags of partitions
> 
> Only read partitions which have 0x00 or 0x80 set in their status field.
> All others are invalid.
> 
> Signed-off-by: Daniel Mack <daniel@caiaq.de>
> ---
>  disk/part_dos.c |    3 ++-
>  1 files changed, 2 insertions(+), 1 deletions(-)
> 
> diff --git a/disk/part_dos.c b/disk/part_dos.c
> index 93bf3dd..e32d58e 100644
> --- a/disk/part_dos.c
> +++ b/disk/part_dos.c
> @@ -188,7 +188,8 @@ static int get_partition_info_extended (block_dev_desc_t *dev_desc, int ext_part
>  		 * fdisk does not show the extended partitions that
>  		 * are not in the MBR
>  		 */
> -		if ((pt->sys_ind != 0) &&
> +		if (((pt->boot_ind & ~0x80) == 0) &&
> +		    (pt->sys_ind != 0) &&
>  		    (part_num == which_part) &&
>  		    (is_extended(pt->sys_ind) == 0)) {
>  			info->blksz = 512;
> -- 
> 1.6.3.3
> 

[U-Boot] [PATCH] part_dos: check status flags of partitions

[Wolfgang Denk]

Dear Daniel Mack,

In message <20091003050534.GO9410@buzzloop.caiaq.de> you wrote:
> ping?

I have a huge backlog. Please be patient with me.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Power is danger.
	-- The Centurion, "Balance of Terror", stardate 1709.2

[U-Boot] [PATCH] part_dos: check status flags of partitions

[Wolfgang Denk]

Dear Daniel Mack,

In message <20090928100400.GY9361@buzzloop.caiaq.de> you wrote:
> The current fatload code has a problem together with the way the DOS
> partition parser is implemented.
> 
> This hit me when I tried to load a file from a USB stick which had no
> partition table but a FAT16 directly written to the first sector.
> 
> With such an environment, get_partition_info_extended() still finds a
> valid partition at the first sector since the 0x55aa magic is valid for
> both the MBR and the FAT boot sector.
> 
> As a result, part_offset in fs/fat/fat.c is then set to some ridiculous
> value and the code searching for the directory entry gets lots in an
> endless loop.
> 
> The fix is quite simple though - we just need to check the status field
> of the partitions more stricly. According to the specs, it may only
> contain 0x00 and 0x80. If get_partition_info() fails for this case, the
> fatload code falls back to the assumption that there is no partition
> table and does the right thing then.
> 
> Please consider applying the following patch.
> 
> Daniel
> 
> 
> From 381a85bf04adc228cc70e8fa7af899a6dbf07e42 Mon Sep 17 00:00:00 2001
> From: Daniel Mack <daniel@caiaq.de>
> Date: Mon, 28 Sep 2009 11:40:38 +0200
> Subject: [PATCH] part_dos: check status flags of partitions
> 
> Only read partitions which have 0x00 or 0x80 set in their status field.
> All others are invalid.
> 
> Signed-off-by: Daniel Mack <daniel@caiaq.de>
> ---
>  disk/part_dos.c |    3 ++-
>  1 files changed, 2 insertions(+), 1 deletions(-)

Applied, thanks.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Digital computers are themselves more complex than most things people
build: They have very large numbers of states. This makes conceiving,
describing, and testing them hard. Software systems  have  orders-of-
magnitude more states than computers do.           - Fred Brooks, Jr.