aboutsummaryrefslogtreecommitdiff
path: root/lib/mpi/mpi-sub-ui.c
diff options
context:
space:
mode:
authorCarlos Llamas <[email protected]>2022-11-04 23:12:35 +0000
committerGreg Kroah-Hartman <[email protected]>2022-11-09 15:41:27 +0100
commit3ce00bb7e91cf57d723905371507af57182c37ef (patch)
treecdf8653469264589c5b4f51350c0e8555ab14f33 /lib/mpi/mpi-sub-ui.c
parentab126f51c93a15093df604f661c9480854c005a3 (diff)
binder: validate alloc->mm in ->mmap() handler
Since commit 1da52815d5f1 ("binder: fix alloc->vma_vm_mm null-ptr dereference") binder caches a pointer to the current->mm during open(). This fixes a null-ptr dereference reported by syzkaller. Unfortunately, it also opens the door for a process to update its mm after the open(), (e.g. via execve) making the cached alloc->mm pointer invalid. Things get worse when the process continues to mmap() a vma. From this point forward, binder will attempt to find this vma using an obsolete alloc->mm reference. Such as in binder_update_page_range(), where the wrong vma is obtained via vma_lookup(), yet binder proceeds to happily insert new pages into it. To avoid this issue fail the ->mmap() callback if we detect a mismatch between the vma->vm_mm and the original alloc->mm pointer. This prevents alloc->vm_addr from getting set, so that any subsequent vma_lookup() calls fail as expected. Fixes: 1da52815d5f1 ("binder: fix alloc->vma_vm_mm null-ptr dereference") Reported-by: Jann Horn <[email protected]> Cc: <[email protected]> # 5.15+ Signed-off-by: Carlos Llamas <[email protected]> Acked-by: Todd Kjos <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Diffstat (limited to 'lib/mpi/mpi-sub-ui.c')
0 files changed, 0 insertions, 0 deletions