The patch titled
Subject: mm/vmalloc: fix size check for remap_vmalloc_range_partial()
has been added to the -mm tree. Its filename is
mm-vmalloc-fix-size-check-for-remap_vmalloc_range_partial.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/mm-vmalloc-fix-size-check-for-remap_vmalloc_range_partial.patch
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/mm-vmalloc-fix-size-check-for-remap_vmalloc_range_partial.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Roman Penyaev <rpenyaev@xxxxxxx>
Subject: mm/vmalloc: fix size check for remap_vmalloc_range_partial()
When VM_NO_GUARD is not set area->size includes adjacent guard page,
thus for correct size checking get_vm_area_size() should be used, but
not area->size.
This fixes possible kernel oops when userspace tries to mmap an area on
1 page bigger than was allocated by vmalloc_user() call: the size check
inside remap_vmalloc_range_partial() accounts non-existing guard page
also, so check successfully passes but vmalloc_to_page() returns NULL
(guard page does not physically exist).
The following code pattern example should trigger an oops:
static int oops_mmap(struct file *file, struct vm_area_struct *vma)
{
void *mem;
mem = vmalloc_user(4096);
BUG_ON(!mem);
/* Do not care about mem leak */
return remap_vmalloc_range(vma, mem, 0);
}
And userspace simply mmaps size + PAGE_SIZE:
mmap(NULL, 8192, PROT_WRITE|PROT_READ, MAP_PRIVATE, fd, 0);
Possible candidates for oops which do not have any explicit size
checks:
*** drivers/media/usb/stkwebcam/stk-webcam.c:
v4l_stk_mmap[789] ret = remap_vmalloc_range(vma, sbuf->buffer, 0);
Or the following one:
*** drivers/video/fbdev/core/fbmem.c
static int
fb_mmap(struct file *file, struct vm_area_struct * vma)
...
res = fb->fb_mmap(info, vma);
Where fb_mmap callback calls remap_vmalloc_range() directly without any
explicit checks:
*** drivers/video/fbdev/vfb.c
static int vfb_mmap(struct fb_info *info,
struct vm_area_struct *vma)
{
return remap_vmalloc_range(vma, (void *)info->fix.smem_start, vma->vm_pgoff);
}
Link: http://lkml.kernel.org/r/20190103145954.16942-2-rpenyaev@xxxxxxx
Signed-off-by: Roman Penyaev <rpenyaev@xxxxxxx>
Acked-by: Michal Hocko <mhocko@xxxxxxxx>
Cc: Andrey Ryabinin <aryabinin@xxxxxxxxxxxxx>
Cc: Joe Perches <joe@xxxxxxxxxxx>
Cc: "Luis R. Rodriguez" <mcgrof@xxxxxxxxxx>
Cc: <stable@xxxxxxxxxxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
---
--- a/mm/vmalloc.c~mm-vmalloc-fix-size-check-for-remap_vmalloc_range_partial
+++ a/mm/vmalloc.c
@@ -2248,7 +2248,7 @@ int remap_vmalloc_range_partial(struct v
if (!(area->flags & VM_USERMAP))
return -EINVAL;
- if (kaddr + size > area->addr + area->size)
+ if (kaddr + size > area->addr + get_vm_area_size(area))
return -EINVAL;
do {
_
Patches currently in -mm which might be from rpenyaev@xxxxxxx are
epoll-make-sure-all-elements-in-ready-list-are-in-fifo-order.patch
epoll-loosen-irq-safety-in-ep_poll_callback.patch
epoll-unify-awaking-of-wakeup-source-on-ep_poll_callback-path.patch
epoll-use-rwlock-in-order-to-reduce-ep_poll_callback-contention.patch
mm-vmalloc-fix-size-check-for-remap_vmalloc_range_partial.patch
mm-vmalloc-do-not-call-kmemleak_free-on-not-yet-accounted-memory.patch
mm-vmalloc-pass-vm_usermap-flags-directly-to-__vmalloc_node_range.patch
