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  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Date:	Thu, 6 Jun 2013 10:43:21 -0400
From:	Theodore Ts'o <>
To:	Andreas Dilger <>
Cc:	Greg KH <>,
	Jonathan Salwan <>,
	"" <>,
	"" <>,
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

> 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

					- Ted
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists