On Tue, Jul 28, 2026 at 06:22:57AM +0800, Barry Song wrote: > 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? > Probably :) But i am not sure what the patch fixes. There is a race anyway?
You check VA on CPU_1 successfully, after that CPU_2 unmaps the pages by calling vrealloc() and CPU_1 is about to read unmapped pages. -- Uladzislau Rezki
