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

Christoph Hellwig
2024-10-10T08:01:39Z

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@mail.gmail.com/T/#u
> It's been removed from -next since then.
>
> It's safe to ignore.

Thanks!