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
