linux-kernel - Re: [PATCH 4.4 01/72] mtd: jedec_probe: Fix crash in jedec_read

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1526310960.9159.3.camel@codethink.co.uk>
Date:   Mon, 14 May 2018 16:16:00 +0100
From:   Ben Hutchings <ben.hutchings@...ethink.co.uk>
To:     Linus Walleij <linus.walleij@...aro.org>,
        Boris Brezillon <boris.brezillon@...tlin.com>
Cc:     stable@...r.kernel.org,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 4.4 01/72] mtd: jedec_probe: Fix crash in
 jedec_read_mfr()

On Fri, 2018-04-06 at 15:23 +0200, Greg Kroah-Hartman wrote:
> 4.4-stable review patch.  If anyone has any objections, please let me know.
> 
> ------------------
> 
> From: Linus Walleij <linus.walleij@...aro.org>
> 
> commit 87a73eb5b56fd6e07c8e499fe8608ef2d8912b82 upstream.
[...]
> --- a/drivers/mtd/chips/jedec_probe.c
> +++ b/drivers/mtd/chips/jedec_probe.c
> @@ -1889,6 +1889,8 @@ static inline u32 jedec_read_mfr(struct
>  	do {
>  		uint32_t ofs = cfi_build_cmd_addr(0 + (bank << 8), map, cfi);
>  		mask = (1 << (cfi->device_type * 8)) - 1;
> +		if (ofs >= map->size)
> +			return 0;
>  		result = map_read(map, base + ofs);
>  		bank++;
>  	} while ((result.x[0] & mask) == CFI_MFR_CONTINUATION);

Looking at the calling code several levels up, in
genprobe_ident_chips():

	max_chips = map->size >> cfi.chipshift;
[...]
	for (i = 1; i < max_chips; i++) {
		cp->probe_chip(map, i << cfi.chipshift, chip_map, &cfi);
	}

The expression i << cfi.chipshift becomes the base parameter here, so
we have base < map->size.  That implies to me that map->size is the
size of the complete mapping, and we need to compare it with the
complete address.

So shouldn't the test be ofs >= (map->size - base)?
Or even ofs >= (1 << cfi->chipshift)?

Ben.

-- 
Ben Hutchings
Software Developer, Codethink Ltd.