Re: [PATCH] xfs: Fix error pointer dereference

From: Darrick J. Wong

Date: Wed Feb 18 2026 - 19:32:00 EST


On Thu, Feb 19, 2026 at 11:25:38AM +1100, NeilBrown wrote:
> On Thu, 19 Feb 2026, Darrick J. Wong wrote:
> > On Wed, Feb 18, 2026 at 01:51:15PM -0600, Ethan Tidmore wrote:
> > > The function try_lookup_noperm() can return an error pointer and is not
> > > checked for one. Add checks for error pointer.
> > >
> > > Detected by Smatch:
> > > fs/xfs/scrub/orphanage.c:449 xrep_adoption_check_dcache() error:
> > > 'd_child' dereferencing possible ERR_PTR()
> > >
> > > fs/xfs/scrub/orphanage.c:485 xrep_adoption_zap_dcache() error:
> > > 'd_child' dereferencing possible ERR_PTR()
> > >
> > > Fixes: 06c567403ae5a ("Use try_lookup_noperm() instead of d_hash_and_lookup() outside of VFS")
> >
> > Cc: <stable@xxxxxxxxxxxxxxx> # v6.16
>
> I don't think this is justified. In this use case try_lookup_noperm()
> will never actually return an error.

Sure, but a future update to try_lookup_noperm that *does* introduce the
possibility of an ERR_PTR return could get backported to 6.18, at which
point this code is now broken. I think I'd rather just clean all this
up all at once.

> >
> > > Signed-off-by: Ethan Tidmore <ethantidmore06@xxxxxxxxx>
> > > ---
> > > fs/xfs/scrub/orphanage.c | 4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/fs/xfs/scrub/orphanage.c b/fs/xfs/scrub/orphanage.c
> > > index 52a108f6d5f4..cdb0f486f50c 100644
> > > --- a/fs/xfs/scrub/orphanage.c
> > > +++ b/fs/xfs/scrub/orphanage.c
> > > @@ -442,7 +442,7 @@ xrep_adoption_check_dcache(
> > > return 0;
> > >
> > > d_child = try_lookup_noperm(&qname, d_orphanage);
> >
> > "Look up a dentry by name in the dcache, returning NULL if it does not
> > currently exist."
> >
> > Could you please fix the documentation since try_lookup_noperm can
> > return ERR_PTR values?
>
> Fair - I'll include a patch with my next batch.
>
> >
> > > - if (d_child) {
> > > + if (!IS_ERR_OR_NULL(d_child)) {
> >
> > If d_child is an ERR_PTR, shouldn't we extract that error value and
> > return it instead of zero?
>
> This is a purely cosmetic question as no error is actually returned in
> practice. So whatever you feel most comfortable with is best.

If we're going to check for an ERR_PTR value (even if one cannot
currently be returned) then we should pass it upwards. We might as well
get rid of all the lurking broken logic all at once.

--D

> NeilBrown
>
>
> >
> > --D
> >
> > > trace_xrep_adoption_check_child(sc->mp, d_child);
> > >
> > > if (d_is_positive(d_child)) {
> > > @@ -479,7 +479,7 @@ xrep_adoption_zap_dcache(
> > > return;
> > >
> > > d_child = try_lookup_noperm(&qname, d_orphanage);
> > > - while (d_child != NULL) {
> > > + while (!IS_ERR_OR_NULL(d_child)) {
> > > trace_xrep_adoption_invalidate_child(sc->mp, d_child);
> > >
> > > ASSERT(d_is_negative(d_child));
> > > --
> > > 2.53.0
> > >
> > >
> >
>
>