kmemleak: Cannot insert 0xffffff806e24f000 into the object search tree (overlaps existing) [RPi CM4]

[Greg Kroah-Hartman]

On Tue, Aug 16, 2022 at 04:39:43PM -0700, Andrew Morton wrote:
> On Tue, 16 Aug 2022 15:26:29 +0100 Will Deacon <will at kernel.org> wrote:
> 
> > On Tue, Aug 16, 2022 at 10:52:19AM +0000, Yee Lee (李建誼) wrote:
> > > The kfence patch(07313a2b29ed) is based on the prior changes in
> > > kmemleak(0c24e061196c2 , merged in v6.0-rc1), but it shows up earlier in
> > > v5.19. 
> > > 
> > > @akpm
> > > Andrew, sorry that the short fix tag caused confusing. Can we pull out the
> > > patch(07313a2b29e) in v5.19.x?
> > > 
> > > Kfence: (07313a2b29ed) https://github.com/torvalds/linux/commit/07313a2b29ed1079eaa7722624544b97b3ead84b
> > > Kmemleak: (0c24e061196c2) https://github.com/torvalds/linux/commit/0c24e061196c21d53328d60f4ad0e5a2b3183343
> > 
> > Hmm, so if I'm understanding correctly then:
> > 
> >  - The kfence fix (07313a2b29ed) depends on a kmemleak change (0c24e061196c2)
> >    but the patches apply cleanly on their own.
> > 
> >  - The kmemleak change landed in the v6.0 merge window, but the kfence fix
> >    landed in 5.19 (and has a fixes tag)
> > 
> > So it sounds like we can either:
> > 
> >  1. Revert 07313a2b29ed in the stable trees which contain it and then fix
> >     the original issue some other way.
> 
> 07313a2b29ed should not be in the stable tree.  It did not have a
> cc:stable and we've asked the stable tree maintainers not to blindly
> backport everything that has a Fixes: tag.
> 
> How did this happen?

I do not see 07313a2b29ed in any stable tree or release that I can
find, am I missing something?

thanks,

greg k-h