linux-ext4 - RE: [PATCH] ext4: FIBMAP ioctl causes BUG_ON due to handle EXT_MAX

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] [day] [month] [year] [list]

Message-ID: <C26C67884C4B7A48980D574635594864E18B2E@BPXM20GP.gisp.nec.co.jp>
Date:	Tue, 1 Apr 2014 06:52:22 +0000
From:	Kazuya Mio <k-mio@...jp.nec.com>
To:	"Theodore Ts'o" <tytso@....edu>
CC:	"adilger.kernel@...ger.ca" <adilger.kernel@...ger.ca>,
	"linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>
Subject: RE: [PATCH] ext4: FIBMAP ioctl causes BUG_ON due to handle
 EXT_MAX_BLOCKS

2014/04/01 14:15:16, Theodore Ts'o wrote:
> We should be returning an error when we pass in an lblk >=
> EXT4_MAX_BLOCKS in ext4_map_blocks(), long before we even get to
> ext4_ext_put_gap_in_cache().  And if we fix it there, we may catch
> other cases which might lead to the BUG_ON() firing.

Agree. I'll send the fixed patch latter.

> Did you check whether the same bug can be triggered via FIEMAP?

FIEMAP ioctl is safe because ext4_fiemap() has the following check.

        last_blk = (start + len - 1) >> inode->i_sb->s_blocksize_bits;
        if (last_blk >= EXT_MAX_BLOCKS)
                 last_blk = EXT_MAX_BLOCKS-1;

AFAIK, FIBMAP is only the way to pass the block number specified by a user to
ext4_map_blocks().

Regards,

Kazuya Mio
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html