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: Thu, 6 Jun 2013 10:43:21 -0400 From: Theodore Ts'o <tytso@....edu> To: Andreas Dilger <adilger@...ger.ca> Cc: Greg KH <greg@...ah.com>, Jonathan Salwan <jonathan.salwan@...il.com>, "adilger.kernel@...ger.ca" <adilger.kernel@...ger.ca>, "security@...nel.org" <security@...nel.org>, linux-ext4@...r.kernel.org Subject: Re: CVE request : Infinite loop in the ext4 support could cause a denial of service. On Wed, Jun 05, 2013 at 09:02:11PM -0600, Andreas Dilger wrote: > > I think with CAP_SYS_RESOURCE there are are quite a number of > DOS attacks possible (e.g. fork bomb). Ah, sorry for my earlier e-mail. I didn't see the PoC code that was quoted at the end of Greg's reply. But I agree, that given that there are plenty of Denial of Service attacks with CAP_SYS_RESOURCE, I don't believe a fix requires any secrecy, so I'll run the patches through the normal ext4 process and the ext4 mailing list. If you want a CVE number for bragging points and/or for your performance metrics (and/or to help Microsoft's propaganda machine), feel free, but I don't consider this as a serious issue, so I don't plan to tag the commit with a CVE number, nor to especially encourage distro's to take this patch, unless someone sees more serious attack vector. > test_root() is called with "a" as the group number (any unsigned > 32-bit number may be valid, depending on filesystem size), and "b" > is 3, 5, and 7 in turn. With b=3, this only takes only 21 loops (i.e. 3^21) for num to exceed 2^32. > > Ah, num is a signed int, and if "a" is 0xffffffff there is no chance > that (a > num) is ever true due to overflow. It would be enough to > make "num" a u64 so that it cannot overflow before it exceeds "a". That's a reasonable fix, but then I'd suggest caching the result of ext4_sparse_group in ext4_group_info --- which would also imply that we would be putting in an sanity check of the group number in ext4_bg_has_super(), or better yet in ext4_get_group_info(). We should also fix this problem another way in verify_group_input() in fs/ext4/resize.c by sanity checking the group number in the ext4_new_group_data structures *before* calling ext4_bg_has_super() or ext4_group_overhead_blocks(). - Ted -- 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