seq_file: disallow extremely large seq buffer allocations

commit 8cae8cd89f05f6de223d63e6d15e31c8ba9cf53b upstream.

There is no reasonable need for a buffer larger than this, and it avoids
int overflow pitfalls.

Fixes: 058504edd026 ("fs/seq_file: fallback to vmalloc allocation")
Suggested-by: Al Viro <viro@zeniv.linux.org.uk>
Reported-by: Qualys Security Advisory <qsa@qualys.com>
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Cc: stable@kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

diff --git a/fs/seq_file.c b/fs/seq_file.c
index 6dc4296eed62c5d2a493c5ba3f649c890aa37981..95e730506ad2b61d97a2de0f4a01c15fe9f9e2c1 100644 (file)
--- a/fs/seq_file.c
+++ b/fs/seq_file.c
@@ -14,6 +14,7 @@
 #include <linux/mm.h>
 #include <linux/printk.h>
 #include <linux/string_helpers.h>
+#include <linux/pagemap.h>
 
 #include <asm/uaccess.h>
 #include <asm/page.h>
@@ -28,6 +29,9 @@ static void *seq_buf_alloc(unsigned long size)
        void *buf;
        gfp_t gfp = GFP_KERNEL;
 
+       if (unlikely(size > MAX_RW_COUNT))
+               return NULL;
+
        /*
         * For high order allocations, use __GFP_NORETRY to avoid oom-killing -
         * it's better to fall back to vmalloc() than to kill things.  For small