RE: [RFC] odd check in ceph_encode_encrypted_dname()

[Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>]

On Wed, 2025-02-19 at 02:18 +0000, Al Viro wrote:
> On Wed, Feb 19, 2025 at 12:58:54AM +0000, Viacheslav Dubeyko wrote:
> > On Tue, 2025-02-18 at 23:52 +0000, Al Viro wrote:
> > > On Tue, Feb 18, 2025 at 01:21:32AM +0000, Al Viro wrote:
> > > 
> > > > See the problem?  strrchr() expects a NUL-terminated string; giving it an
> > > > array that has no zero bytes in it is an UB.
> > > > 
> > > > That one is -stable fodder on its own, IMO...
> > > 
> > > FWIW, it's more unpleasant; there are other call chains for parse_longname()
> > > where it's not feasible to NUL-terminate in place.  I suspect that the
> > > patch below is a better way to handle that.  Comments?
> > > 
> > 
> > Let me test the patch.
> 
> That one is on top of mainline (-rc2); the entire branch is
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git #d_name
> 
> The first commit in there is this one, then two posted earlier rebased
> on top of that (without the "NUL-terminate in place" in the last one,
> which is what tripped KASAN and is no longer needed due to the first
> commit).

I have tested patchset by xfstests and I have played with snapshots manually. I
haven't found any new or critical issues. Everything looks good.

Tested-by: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>

Thanks,
Slava.