* [PATCH] xfs: Fix error pointer dereference
@ 2026-02-18 19:51 Ethan Tidmore
2026-02-18 23:49 ` Darrick J. Wong
` (2 more replies)
0 siblings, 3 replies; 7+ messages in thread
From: Ethan Tidmore @ 2026-02-18 19:51 UTC (permalink / raw)
To: Carlos Maiolino, NeilBrown
Cc: Christian Brauner, linux-xfs, linux-kernel, Ethan Tidmore
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")
Signed-off-by: Ethan Tidmore <ethantidmore06@gmail.com>
---
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);
- if (d_child) {
+ if (!IS_ERR_OR_NULL(d_child)) {
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
^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH] xfs: Fix error pointer dereference
2026-02-18 19:51 [PATCH] xfs: Fix error pointer dereference Ethan Tidmore
@ 2026-02-18 23:49 ` Darrick J. Wong
2026-02-19 0:25 ` NeilBrown
2026-02-19 0:21 ` NeilBrown
2026-02-19 11:26 ` Nirjhar Roy (IBM)
2 siblings, 1 reply; 7+ messages in thread
From: Darrick J. Wong @ 2026-02-18 23:49 UTC (permalink / raw)
To: Ethan Tidmore
Cc: Carlos Maiolino, NeilBrown, Christian Brauner, linux-xfs,
linux-kernel
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@vger.kernel.org> # v6.16
> Signed-off-by: Ethan Tidmore <ethantidmore06@gmail.com>
> ---
> 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?
> - 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?
--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
>
>
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] xfs: Fix error pointer dereference
2026-02-18 19:51 [PATCH] xfs: Fix error pointer dereference Ethan Tidmore
2026-02-18 23:49 ` Darrick J. Wong
@ 2026-02-19 0:21 ` NeilBrown
2026-02-19 11:26 ` Nirjhar Roy (IBM)
2 siblings, 0 replies; 7+ messages in thread
From: NeilBrown @ 2026-02-19 0:21 UTC (permalink / raw)
To: Ethan Tidmore
Cc: Carlos Maiolino, Christian Brauner, linux-xfs, linux-kernel,
Ethan Tidmore
On Thu, 19 Feb 2026, 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")
This commit didn't introduce this behaviour.
It changed from using d_hash_and_lookup() to using try_lookup_noperm().
Both can return an ERR_PTR(). Neither ever do in this code.
As the lookup only happens in an XFS filesystem and as XFS doesn't
define d_hash(), d_hash_and_lookup() would never actually return an
error.
try_lookup_noperm() does add some error cases for, e.g. , "." and ".."
and names containing "/". But none of these apply here.
So this is worth fixing, but the current code has been like this since
it was written, so
Fixes: 73597e3e42b4 ("xfs: ensure dentry consistency when the orphanage adopts a file")
would be more appropriate.
Thanks,
NeilBrown
> Signed-off-by: Ethan Tidmore <ethantidmore06@gmail.com>
> ---
> 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);
> - if (d_child) {
> + if (!IS_ERR_OR_NULL(d_child)) {
> 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
>
>
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] xfs: Fix error pointer dereference
2026-02-18 23:49 ` Darrick J. Wong
@ 2026-02-19 0:25 ` NeilBrown
2026-02-19 0:31 ` Darrick J. Wong
0 siblings, 1 reply; 7+ messages in thread
From: NeilBrown @ 2026-02-19 0:25 UTC (permalink / raw)
To: Darrick J. Wong
Cc: Ethan Tidmore, Carlos Maiolino, Christian Brauner, linux-xfs,
linux-kernel
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@vger.kernel.org> # v6.16
I don't think this is justified. In this use case try_lookup_noperm()
will never actually return an error.
>
> > Signed-off-by: Ethan Tidmore <ethantidmore06@gmail.com>
> > ---
> > 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.
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
> >
> >
>
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] xfs: Fix error pointer dereference
2026-02-19 0:25 ` NeilBrown
@ 2026-02-19 0:31 ` Darrick J. Wong
0 siblings, 0 replies; 7+ messages in thread
From: Darrick J. Wong @ 2026-02-19 0:31 UTC (permalink / raw)
To: NeilBrown
Cc: Ethan Tidmore, Carlos Maiolino, Christian Brauner, linux-xfs,
linux-kernel
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@vger.kernel.org> # 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@gmail.com>
> > > ---
> > > 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
> > >
> > >
> >
>
>
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] xfs: Fix error pointer dereference
2026-02-18 19:51 [PATCH] xfs: Fix error pointer dereference Ethan Tidmore
2026-02-18 23:49 ` Darrick J. Wong
2026-02-19 0:21 ` NeilBrown
@ 2026-02-19 11:26 ` Nirjhar Roy (IBM)
2026-02-19 16:46 ` Ethan Tidmore
2 siblings, 1 reply; 7+ messages in thread
From: Nirjhar Roy (IBM) @ 2026-02-19 11:26 UTC (permalink / raw)
To: Ethan Tidmore, Carlos Maiolino, NeilBrown
Cc: Christian Brauner, linux-xfs, linux-kernel
On Wed, 2026-02-18 at 13:51 -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.
Nit:In the subject, maybe just add the function name where the error pointer dereference is being
fixed?
>
> 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")
> Signed-off-by: Ethan Tidmore <ethantidmore06@gmail.com>
> ---
> 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);
> - if (d_child) {
> + if (!IS_ERR_OR_NULL(d_child)) {
> 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);
Based on my limited knowledge of this change looks okay to me. I looked into the return values of
try_lookup_noperm() and it does return error pointer which is not NULL. I also checked the other
call sites of try_lookup_noperm() but I do see a mixed handling i.e, some places just checks for
!ptr and some for IS_ERR_OR_NULL. For example in fs/autofs it checks with IS_ERR_OR_NULL whereas in
fs/proc/base.c it just checks for !child. However, IMO, it is better to check for both NULL and
error pointer if there is a possibility for both.
--NR
>
> ASSERT(d_is_negative(d_child));
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] xfs: Fix error pointer dereference
2026-02-19 11:26 ` Nirjhar Roy (IBM)
@ 2026-02-19 16:46 ` Ethan Tidmore
0 siblings, 0 replies; 7+ messages in thread
From: Ethan Tidmore @ 2026-02-19 16:46 UTC (permalink / raw)
To: Nirjhar Roy (IBM), Ethan Tidmore, Carlos Maiolino, NeilBrown
Cc: Christian Brauner, linux-xfs, linux-kernel
On Thu Feb 19, 2026 at 5:26 AM CST, Nirjhar Roy (IBM) wrote:
> On Wed, 2026-02-18 at 13:51 -0600, Ethan Tidmore wrote:
...
>
> Based on my limited knowledge of this change looks okay to me. I looked into the return values of
> try_lookup_noperm() and it does return error pointer which is not NULL. I also checked the other
> call sites of try_lookup_noperm() but I do see a mixed handling i.e, some places just checks for
> !ptr and some for IS_ERR_OR_NULL. For example in fs/autofs it checks with IS_ERR_OR_NULL whereas in
> fs/proc/base.c it just checks for !child. However, IMO, it is better to check for both NULL and
> error pointer if there is a possibility for both.
> --NR
I was already planning on sending a patch to fs/proc/base.c also. Smatch
was complaining there too.
Thanks,
ET
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2026-02-19 16:46 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-02-18 19:51 [PATCH] xfs: Fix error pointer dereference Ethan Tidmore
2026-02-18 23:49 ` Darrick J. Wong
2026-02-19 0:25 ` NeilBrown
2026-02-19 0:31 ` Darrick J. Wong
2026-02-19 0:21 ` NeilBrown
2026-02-19 11:26 ` Nirjhar Roy (IBM)
2026-02-19 16:46 ` Ethan Tidmore
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox