Bug 194695 - size overflow detected in function ext4_mb_new_group_pa
Summary: size overflow detected in function ext4_mb_new_group_pa
Status: NEW
Alias: None
Product: File System
Classification: Unclassified
Component: ext4 (show other bugs)
Hardware: x86-64 Linux
: P1 normal
Assignee: fs_ext4@kernel-bugs.osdl.org
Depends on:
Reported: 2017-02-24 13:11 UTC by Matthijs Möhlmann
Modified: 2017-02-28 05:28 UTC (History)
3 users (show)

See Also:
Kernel Version: 4.9.10-1+grsec201702162016+1
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:

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
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....

Note You need to log in before you can comment on or make changes to this bug.