Re: [syzbot] [xfs?] KFENCE: memory corruption in xfs_idata_realloc

[Christoph Hellwig]

On Thu, Oct 10, 2024 at 09:50:06AM +0200, Marco Elver wrote:
> > I've tried to make sense of this report and failed.
> >
> > Documentation/dev-tools/kfence.rst explains these messages as:
> >
> > KFENCE also uses pattern-based redzones on the other side of an object's guard
> > page, to detect out-of-bounds writes on the unprotected side of the object.
> > These are reported on frees::
> >
> > But doesn't explain what "the other side of an object's guard page" is.
> 
> Every kfence object has a guard page right next to where it's allocated:
> 
>   [ GUARD | OBJECT + "wasted space" ]
> 
> or
> 
>   [ "wasted space" + OBJECT | GUARD ]
> 
> The GUARD is randomly on the left or right. If an OOB access straddles
> into the GUARD, we get a page fault. For objects smaller than
> page-size, there'll be some "wasted space" on the object page, which
> is on "the other side" vs. where the guard page is. If a OOB write or
> other random memory corruption doesn't hit the GUARD, but the "wasted
> space" portion next to an object that would be detected as "Corrupted
> memory" on free because the redzone pattern was likely stomped on.

Thanks!  Searching kfence.txt for random I find that explaination in
the intro now.  Can you maybe expand the section I quoted to make
this more clear, by saying something like:

KFENCE also uses pattern-based redzones on the side of the object that
is not covered by the GUARD (which is randomly allocated to either the
left or the right), to detect out-of-bounds writes there as well.
These are reported on frees::


> 
> > Either way this is in the common krealloc code, which is a bit special
> > as it uses ksize to figure out what the actual underlying allocation
> > size of an object is to make use of that.  Without understanding the
> > actual error I wonder if that's something kfence can't cope with?
> 
> krealloc + KFENCE broke in next-20241003:
> https://lore.kernel.org/all/CANpmjNM5XjwwSc8WrDE9=FGmSScftYrbsvC+db+82GaMPiQqvQ@xxxxxxxxxxxxxx/T/#u
> It's been removed from -next since then.
> 
> It's safe to ignore.

Thanks!