diff options
| author | Theodore Ts'o <tytso@mit.edu> | 2013-03-11 23:39:59 -0400 |
|---|---|---|
| committer | Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 2013-04-05 10:16:52 -0700 |
| commit | 503f4bdcc078e7abee273a85ce322de81b18a224 (patch) | |
| tree | 30eb5483102eb88ac8e5d9c9ddb84e6437ddd6ba /kernel | |
| parent | 7fb54baf47818c2a76999ff907e2cecf25b98218 (diff) | |
| download | kernel_samsung_aries-503f4bdcc078e7abee273a85ce322de81b18a224.zip kernel_samsung_aries-503f4bdcc078e7abee273a85ce322de81b18a224.tar.gz kernel_samsung_aries-503f4bdcc078e7abee273a85ce322de81b18a224.tar.bz2 | |
ext4: use atomic64_t for the per-flexbg free_clusters count
commit 90ba983f6889e65a3b506b30dc606aa9d1d46cd2 upstream.
A user who was using a 8TB+ file system and with a very large flexbg
size (> 65536) could cause the atomic_t used in the struct flex_groups
to overflow. This was detected by PaX security patchset:
http://forums.grsecurity.net/viewtopic.php?f=3&t=3289&p=12551#p12551
This bug was introduced in commit 9f24e4208f7e, so it's been around
since 2.6.30. :-(
Fix this by using an atomic64_t for struct orlav_stats's
free_clusters.
[Backported for 3.0-stable. Renamed free_clusters back to free_blocks;
fixed a few more atomic_read's of free_blocks left in 3.0.]
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Reviewed-by: Lukas Czerner <lczerner@redhat.com>
Signed-off-by: Lingzhu Xiang <lxiang@redhat.com>
Reviewed-by: CAI Qian <caiqian@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'kernel')
0 files changed, 0 insertions, 0 deletions