Re: [PATCH] mm/usercopy: harden bounds checking for vmalloc allocations

On Mon, Jul 27, 2026 at 5:32 PM Uladzislau Rezki <[email protected]> wrote:
>
> On Mon, Jul 27, 2026 at 12:33:49PM +0530, Dev Jain wrote:
> >
> >
> > On 26/07/26 4:16 pm, Matthew Wilcox wrote:
> > > On Sun, Jul 26, 2026 at 02:23:20PM +0530, Dev Jain wrote:
> > >> On 22/07/26 7:59 pm, Dev Jain wrote:
> > >>> The vmalloc allocator stores the actual allocation size inside the
> > >>> vm_struct structure. We can use this bound in usercopy instead of the
> > >>> page-aligned va_end to catch usercopy beyond the actual allocation size.
> > >>>
> > >>> For vmap, the requested_size field is always page-aligned since it maps a
> > >>> certain number of pages. Same for vm_map_ram (alongwith, not even having
> > >>> a vm_struct). So the check is only relevant for vmalloc mappings.
> > >>>
> > >>> Because there are early vm areas registered even before vmalloc_init,
> > >>> requested_size may be zero. So also check whether the requested_size
> > >>> is set.
> > >>>
> > >>> Signed-off-by: Dev Jain <[email protected]>
> > >>> ---
> > >>
> > >> Sashiko:
> > >>
> > >> 1. "Does this locklessly access area->vm after find_vmap_area() has dropped
> > >> the busy tree lock?
> > >>
> > >> If an out-of-bounds pointer falls into an adjacent vmap_area, and that
> > >> adjacent area is concurrently freed by another thread, its vm_struct
> > >> is freed. Additionally, when the vmap_area is moved to the free tree,
> > >> area->vm (which shares a union with subtree_max_size) is overwritten
> > >> with an integer size.
> > >>
> > >> Would dereferencing vm->flags later in this function cause a use-after-free
> > >> or a wild pointer dereference?"
> > >>
> > >>
> > >> I don't get it. So usercopy is checking OOB for an object but shouldn't
> > >> assume the existence of that object while using it?
> > >>
> > >> It is a bug in the caller if someone does vfree() while usercopy is operating
> > >> on the vmalloc object. I don't think usercopy should handle it. For example
> > >> we don't handle it for slabs currently.
> > >
> > > I think the question Sashiko is getting to is how we handle:
> > >
> > >     char *p = vmalloc();
> > >     copy_to_user(p - 4);
> >
> > Thanks Willy, I completely misread Sashiko's point.
> >
> > I think this is an existing problem? We are using area->va_end currently,
> > so we can access freed memory.
> >
> It is a bit mess here since now we need also take into account a
> requested_size due to vrealloc. We have requested_size, nr_pages
> and size in the vm_struct.


I see that vrealloc() always updates vm->requested_size to the new size.
So we could always use requested_size? no?

void *vrealloc_node_align_noprof(const void *p, size_t size, unsigned
long align,
                                 gfp_t flags, int nid)
{
        ...
        if (size <= old_size) {
                ...
                vm->requested_size = size;
                kasan_vrealloc(p, old_size, size);
                return (void *)p;
        }

        /*
         * We already have the bytes available in the allocation; use them.
         */
        if (size <= vm->nr_pages << PAGE_SHIFT) {
                /*
                 * No need to zero memory here, as unused memory will have
                 * already been zeroed at initial allocation time or during
                 * realloc shrink time.
                 */
                vm->requested_size = size;
                kasan_vrealloc(p, old_size, size);
                return (void *)p;
        }

Best Regards
Barry