| Message ID | 87tudjn3or.fsf_-_@email.froward.int.ebiederm.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Fix fill_files_note | expand |
On Mon, Jan 31, 2022 at 7:46 PM Eric W. Biederman <ebiederm@xmission.com> wrote: > 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. > > Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com> Reviewed-by: Jann Horn <jannh@google.com>
diff --git a/fs/coredump.c b/fs/coredump.c index def2a0c9cb14..c5e7d63525c6 100644 --- a/fs/coredump.c +++ b/fs/coredump.c @@ -1127,10 +1127,5 @@ 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; - } - return true; }
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. Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com> --- fs/coredump.c | 5 ----- 1 file changed, 5 deletions(-)