| 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
| ||
|
Date: Fri, 3 Aug 2007 12:09:16 -0600 From: Andreas Dilger <adilger@...sterfs.com> To: Yan Zheng <yanzheng@...n.com> Cc: linux-ext4@...r.kernel.org Subject: Re: How to insure ext4_alloc_blocks always returns blocks below 0xffffffff when using indirect index. On Aug 03, 2007 10:22 +0800, Yan Zheng wrote: > Druing reading the source codes of indirect index, there is a doubt > in my mind. When using indirect index, physical block number must not > exceed 0xffffffff, but I cann' t find any clue about how > ext4_alloc_blocks insure that. Codes that check 64bit_feature is only > in ext4_fill_super and they do nothing affects block allocation > algorithm. Maybe ext4_alloc_blocks should check whether inode has > EXT4_EXTENTS_FL flags and only search block groups that have blocks > below 0xffffffff when not. > > The source codes I read is 2.6.22. Good question. It is intended that extents be used for filesystems larger than 2^32 blocks, but there is no guarantee that existing block-mapped files will not still exist. I think the check you propose makes sense. The code should return EFBIG or maybe EOVERFLOW in this case (not ENOSPC I think). Cheers, Andreas -- Andreas Dilger Principal Software Engineer Cluster File Systems, Inc. - 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
Powered by blists - more mailing lists