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")
Issue: FP3SEC-160
Change-Id: I9146bf107c54eec606b5ce468e22d47674ddf14e
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>
(cherry picked from commit 82280f83d873caccddeeaf6de343762e79969f52)
diff --git a/fs/seq_file.c b/fs/seq_file.c
index 368bfb9..3ade39e 100644
--- a/fs/seq_file.c
+++ b/fs/seq_file.c
@@ -28,6 +28,9 @@
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