linux-kernel - [PATCH] ext4: fix ext4_find_extent() allocation with order >= MAX

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:	Mon, 14 Dec 2015 00:47:12 +0100
From:	Vegard Nossum <vegard.nossum@...cle.com>
To:	tytso@....edu, adilger.kernel@...ger.ca
Cc:	linux-ext4@...r.kernel.org, linux-kernel@...r.kernel.org,
	Vegard Nossum <vegard.nossum@...cle.com>,
	Quentin Casasnovas <quentin.casasnovas@...cle.com>,
	stable@...r.kernel.org
Subject: [PATCH] ext4: fix ext4_find_extent() allocation with order >= MAX_ORDER

Mounting a fuzzed ext4 image on a recent linus/master I see the
following warning:

[ 2.370000] ------------[ cut here ]------------
[ 2.370000] WARNING: CPU: 0 PID: 1005 at mm/page_alloc.c:2989 __alloc_pages_nodemask+0x1afe/0x1d90()
[ 2.370000] Kernel panic - not syncing: panic_on_warn set ...
[ 2.370000]
[ 2.370000] CPU: 0 PID: 1005 Comm: ext4.exe Not tainted 4.4.0-rc4 #1
[ 2.370000] Stack:
[ 2.370000] e0eed440 601097ab 00000000 6187e780
[ 2.370000] 611ba838 601ada46 e0eed460 60acf851
[ 2.370000] 60acf814 60aef320 e0eed580 601ad587
[ 2.370000] Call Trace:
[ 2.370000] [<6005852e>] show_stack+0x1fe/0x430
[ 2.370000] [<60acf851>] dump_stack+0x3d/0x4c
[ 2.370000] [<601ad587>] panic+0x206/0x5be
[ 2.370000] [<60089923>] warn_slowpath_common+0x1e3/0x1f0
[ 2.370000] [<60089b84>] warn_slowpath_null+0x34/0x40
[ 2.370000] [<601c48ce>] __alloc_pages_nodemask+0x1afe/0x1d90
[ 2.370000] [<601c4f0f>] alloc_kmem_pages+0x2f/0x40
[ 2.370000] [<601f6e12>] kmalloc_order+0x32/0xc0
[ 2.370000] [<60246270>] __kmalloc+0x340/0x450
[ 2.370000] [<604469b4>] ext4_find_extent+0x3e4/0x6b0
[ 2.370000] [<60450074>] ext4_ext_map_blocks+0x84/0x2770
[ 2.370000] [<603fb68b>] ext4_map_blocks+0xfb/0xd80
[ 2.370000] [<603fc442>] _ext4_get_block+0x132/0x3c0
[ 2.370000] [<603fd3ab>] ext4_get_block+0x2b/0x40
[...]

This is mm/page_alloc.c:2989 __alloc_pages_nodemask+0x1afe/0x1d90():

	if (order >= MAX_ORDER) {
		WARN_ON_ONCE(!(gfp_mask & __GFP_NOWARN));

and the call into the memory allocator is coming from ext4_find_extent():

	if (!path) {
		/* account possible depth increase */
		path = kzalloc(sizeof(struct ext4_ext_path) * (depth + 2),
			GFP_NOFS);

The problem is that the 'depth' variable is a plain 'short', whereas
the value from the inode is a unsigned 16-bit number; in my case, its
value was -3328.

Simply changing the depth variable to be unsigned short is not
advisable, as that could still break on edge cases like 0xffff in the
subsequent loop without extra care.

Signed-off-by: Vegard Nossum <vegard.nossum@...cle.com>
Cc: Quentin Casasnovas <quentin.casasnovas@...cle.com>
Cc: stable@...r.kernel.org
---
 fs/ext4/extents.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git fs/ext4/extents.c fs/ext4/extents.c
index 551353b..a069cff 100644
--- fs/ext4/extents.c
+++ fs/ext4/extents.c
@@ -863,7 +863,7 @@ ext4_find_extent(struct inode *inode, ext4_lblk_t block,
 	struct ext4_extent_header *eh;
 	struct buffer_head *bh;
 	struct ext4_ext_path *path = orig_path ? *orig_path : NULL;
-	short int depth, i, ppos = 0;
+	int depth, i, ppos = 0;
 	int ret;
 
 	eh = ext_inode_hdr(inode);
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/