diff options
Diffstat (limited to 'meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2020-29372/0001-mm-check-that-mm-is-still-valid-in-madvise.patch')
| -rw-r--r-- | meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2020-29372/0001-mm-check-that-mm-is-still-valid-in-madvise.patch | 72 |
1 files changed, 72 insertions, 0 deletions
diff --git a/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2020-29372/0001-mm-check-that-mm-is-still-valid-in-madvise.patch b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2020-29372/0001-mm-check-that-mm-is-still-valid-in-madvise.patch new file mode 100644 index 000000000..80519ac8d --- /dev/null +++ b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2020-29372/0001-mm-check-that-mm-is-still-valid-in-madvise.patch @@ -0,0 +1,72 @@ +From bc0c4d1e176eeb614dc8734fc3ace34292771f11 Mon Sep 17 00:00:00 2001 +From: Linus Torvalds <torvalds@linux-foundation.org> +Date: Fri, 24 Apr 2020 11:10:58 -0700 +Subject: [PATCH] mm: check that mm is still valid in madvise() + +IORING_OP_MADVISE can end up basically doing mprotect() on the VM of +another process, which means that it can race with our crazy core dump +handling which accesses the VM state without holding the mmap_sem +(because it incorrectly thinks that it is the final user). + +This is clearly a core dumping problem, but we've never fixed it the +right way, and instead have the notion of "check that the mm is still +ok" using mmget_still_valid() after getting the mmap_sem for writing in +any situation where we're not the original VM thread. + +See commit 04f5866e41fb ("coredump: fix race condition between +mmget_not_zero()/get_task_mm() and core dumping") for more background on +this whole mmget_still_valid() thing. You might want to have a barf bag +handy when you do. + +We're discussing just fixing this properly in the only remaining core +dumping routines. But even if we do that, let's make do_madvise() do +the right thing, and then when we fix core dumping, we can remove all +these mmget_still_valid() checks. + +Reported-and-tested-by: Jann Horn <jannh@google.com> +Fixes: c1ca757bd6f4 ("io_uring: add IORING_OP_MADVISE") +Acked-by: Jens Axboe <axboe@kernel.dk> +Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> +--- + mm/madvise.c | 18 ++++++++++++++++++ + 1 file changed, 18 insertions(+) + +diff --git a/mm/madvise.c b/mm/madvise.c +index 4bb30ed6c8d2..8cbd8c1bfe15 100644 +--- a/mm/madvise.c ++++ b/mm/madvise.c +@@ -27,6 +27,7 @@ + #include <linux/swapops.h> + #include <linux/shmem_fs.h> + #include <linux/mmu_notifier.h> ++#include <linux/sched/mm.h> + + #include <asm/tlb.h> + +@@ -1090,6 +1091,23 @@ int do_madvise(unsigned long start, size_t len_in, int behavior) + if (write) { + if (down_write_killable(¤t->mm->mmap_sem)) + return -EINTR; ++ ++ /* ++ * We may have stolen the mm from another process ++ * that is undergoing core dumping. ++ * ++ * Right now that's io_ring, in the future it may ++ * be remote process management and not "current" ++ * at all. ++ * ++ * We need to fix core dumping to not do this, ++ * but for now we have the mmget_still_valid() ++ * model. ++ */ ++ if (!mmget_still_valid(current->mm)) { ++ up_write(¤t->mm->mmap_sem); ++ return -EINTR; ++ } + } else { + down_read(¤t->mm->mmap_sem); + } +-- +2.17.1 + |