summaryrefslogtreecommitdiffstats
path: root/fs/coredump.c
diff options
context:
space:
mode:
authorEric W. Biederman <ebiederm@xmission.com>2022-03-08 20:01:19 +0100
committerEric W. Biederman <ebiederm@xmission.com>2022-03-08 20:01:19 +0100
commit49c1866348f364478a0c4d3dd13fd08bb82d3a5b (patch)
tree3c6ff230f2d84c587a0259dcd30bce7a29583990 /fs/coredump.c
parentcoredump: Snapshot the vmas in do_coredump (diff)
downloadlinux-49c1866348f364478a0c4d3dd13fd08bb82d3a5b.tar.xz
linux-49c1866348f364478a0c4d3dd13fd08bb82d3a5b.zip
coredump: Remove the WARN_ON in dump_vma_snapshot
The condition is impossible and to the best of my knowledge has never triggered. We are in deep trouble if that conditions happens and we walk past the end of our allocated array. So delete the WARN_ON and the code that makes it look like the kernel can handle the case of walking past the end of it's vma_meta array. Reviewed-by: Jann Horn <jannh@google.com> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Diffstat (limited to 'fs/coredump.c')
-rw-r--r--fs/coredump.c6
1 files changed, 0 insertions, 6 deletions
diff --git a/fs/coredump.c b/fs/coredump.c
index 88ac67994d03..7f100a637264 100644
--- a/fs/coredump.c
+++ b/fs/coredump.c
@@ -1139,12 +1139,6 @@ static bool dump_vma_snapshot(struct coredump_params *cprm)
mmap_write_unlock(mm);
- if (WARN_ON(i != cprm->vma_count)) {
- kvfree(cprm->vma_meta);
- return false;
- }
-
-
for (i = 0; i < cprm->vma_count; i++) {
struct core_vma_metadata *m = cprm->vma_meta + i;