linux-kernel - Re: [PATCH 1/2] nfsd: map the ELOOP to nfserr

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-id: <173880416944.22054.14559337357110702284@noble.neil.brown.name>
Date: Thu, 06 Feb 2025 12:09:29 +1100
From: "NeilBrown" <neilb@...e.de>
To: "Chuck Lever" <chuck.lever@...cle.com>
Cc: "Li Lingfeng" <lilingfeng3@...wei.com>, jlayton@...nel.org,
 okorniev@...hat.com, Dai.Ngo@...cle.com, tom@...pey.com,
 trondmy@...merspace.com, linux-nfs@...r.kernel.org,
 linux-kernel@...r.kernel.org, yukuai1@...weicloud.com, houtao1@...wei.com,
 yi.zhang@...wei.com, yangerkun@...wei.com, lilingfeng@...weicloud.com
Subject:
 Re: [PATCH 1/2] nfsd: map the ELOOP to nfserr_symlink to avoid warning

On Thu, 06 Feb 2025, Chuck Lever wrote:
> 
> It's kind of interesting that there hasn't been a need to add an ELOOP
> mapping to nfserrno() until now. I'm a little hesitant to add a generic
> mapping without checking the thousand other places nfserrno() is called,
> but that might end up being a necessary part of this fix.

This ELOOP error is surprising on a local filesystem.  It means that the
lookup of the given name found an inode for a directory which already
existed in the dcache as an ancestor of the directory being listed - or
possibly as the directory itself.  For ext4, that means a corrupt
filesystem.

If the exported filesystem was NFS, then I think it is credible that a
complex race could result in this.

So we certainly need to handle ELOOP cleanly but we don't need to try
too hard to find a perfect solution.  Returning nfserr_io would be
defensible.  Nothing else really suits, certainly not NFS4ERR_SYMLINK
because there is no symlink involved here.

NeilBrown