Bug 194695

Summary:	size overflow detected in function ext4_mb_new_group_pa
Product:	File System	Reporter:	Matthijs Möhlmann (matthijs)
Component:	ext4	Assignee:	fs_ext4 (fs_ext4)
Status:	NEW ---
Severity:	normal	CC:	adilger.kernelbugzilla, pageexec, tytso
Priority:	P1
Hardware:	x86-64
OS:	Linux
Kernel Version:	4.9.10-1+grsec201702162016+1	Subsystem:
Regression:	No	Bisected commit-id:

Description Matthijs Möhlmann 2017-02-24 13:11:16 UTC

I am trying to run a kernel with grsecurity with the size overflow
protection and am getting the following warnings / errors:

dmesg: http://pastebin.com/wr3UGLS9
config: http://pastebin.com/sr8M9bP0
mballoc.* (make fs/ext4/mballoc.o EXTRA_CFLAGS="-fdump-tree-all
-fdump-ipa-all") http://filebin.ca/3DMIChVw9lQM/mballoc.tgz

According to the grsecurity developers it seems to be a bug in ext4, see for some background here:
https://forums.grsecurity.net/viewtopic.php?f=1&t=4678&p=16971

The response from ephox (PAX team / grsecurity developer):
--
Thanks for the report. I think this is an upstream bug. Based on the
runtime values provided by you, ext4_mb_new_group_pa() tries to store a
value into pa->pa_lstart which larger than UINT_MAX which comes from
ext4_group_first_block_no().
Could you please report it to the ext4 developers?
--

I'll try to answer all the questions but I'm not an expert in this area.

Comment 1 Andreas Dilger 2017-02-27 20:55:18 UTC

Definitely looks like a real bug in:

        pa->pa_pstart = ext4_grp_offs_to_block(sb, &ac->ac_b_ex);
        pa->pa_lstart = pa->pa_pstart;

pa_pstart is 64-bit, pa_lstart is 32-bit.

Comment 2 Theodore Tso 2017-02-28 05:28:49 UTC

I don't think we use the pa_lstart value for group preallocations --- a logical number doesn't really have meaning for group pa's.  That being said, the preallocation code is really quite a mess, and it makes it hard to follow.   We should really look at cleaning it up....