linux-ext4 - Re: [PATCH] ext4: avoid possible overflow in ext4_map

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]

Date:	Wed, 19 Feb 2014 22:11:34 -0800
From:	Andreas Dilger <adilger@...ger.ca>
To:	Theodore Ts'o <tytso@....edu>
Cc:	Ext4 Developers List <linux-ext4@...r.kernel.org>
Subject: Re: [PATCH] ext4: avoid possible overflow in ext4_map_blocks()


On Feb 19, 2014, at 9:50 PM, Theodore Ts'o <tytso@....edu> wrote:
> The ext4_map_blocks() function returns the number of blocks which
> satisfying the caller's request.  This number of blocks requested by
> the caller is specified by an unsigned integer, but the return value
> of ext4_map_blocks() is a signed integer (to accomodate error codes
> per the kernel's standard error signalling convention).

[snip]
> return a number large enough that it would overflow a signed integer,
> resultimg in a ext4 thinking that the ext4_map_blocks() call had

(typo) s/resultimg/resulting/

> @@ -514,6 +514,9 @@ int ext4_map_blocks(handle_t *handle, struct inode *inode,
> 		  "logical block %lu\n", inode->i_ino, flags, map->m_len,
> 		  (unsigned long) map->m_lblk);
> 
> +	if (map->m_len >= (1UL << 31))
> +		map->m_len = (1UL << 31) - 1;
> +

Should this instead be INT_MAX?  That makes it more clear why the limit
is here, and in theory on a platform with 64-bit int it would work
properly with a value over (2^31 - 1).

Cheers, Andreas






Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)