On Fri, Oct 04, 2024 at 05:52:10PM +0800, Vlastimil Babka wrote: > On 10/4/24 11:18, Vlastimil Babka wrote: > > On 10/4/24 08:44, Marco Elver wrote: > > > > I think it's commit d0a38fad51cc7 doing in __do_krealloc() > > > > - ks = ksize(p); > > + > > + s = virt_to_cache(p); > > + orig_size = get_orig_size(s, (void *)p); > > + ks = s->object_size; > > > > so for kfence objects we don't get their actual allocation size but the > > potentially larger bucket size? > > > > I guess we could do: > > > > ks = kfence_ksize(p) ?: s->object_size; > > > > ? > > Hmm this probably is not the whole story, we also have: > > - memcpy(ret, kasan_reset_tag(p), ks); > + if (orig_size) > + memcpy(ret, kasan_reset_tag(p), orig_size); > > orig_size for kfence will be again s->object_size so the memcpy might be a > (read) buffer overflow from a kfence allocation. > > I think get_orig_size() should perhaps return kfence_ksize(p) for kfence > allocations, in addition to the change above. > > Or alternatively we don't change get_orig_size() (in a different commit) at > all, but __do_krealloc() will have an "if is_kfence_address()" that sets > both orig_size and ks to kfence_ksize(p) appropriately. That might be easier > to follow. > > But either way means rewriting 2 commits. I think it's indeed better to drop > the series now from -next and submit a v3. Yes, we can revert now. Sorry for the inconvenience. Thanks, Feng
