Re: [Bug report] xfstests generic/323 over NFS hit BUG: KASAN: slab-use-after-free in nfs_local_call_read on 6.18.0-rc1

[Mike Snitzer <snitzer@kernel.org>]

On Sun, Oct 19, 2025 at 12:26:25PM -0400, Mike Snitzer wrote:
> On Sun, Oct 19, 2025 at 11:18:57AM -0400, Trond Myklebust wrote:
> > On Sun, 2025-10-19 at 17:29 +0800, Yongcheng Yang wrote:
> > > Hi All,
> > > 
> > > There is a new nfs slab-use-after-free issue since 6.18.0-rc1.
> > > It appears to be reliably reproducible on my side when running
> > > xfstests
> > > generic/323 over NFSv4.2 in *debug* kernel mode:
> > 
> > Thanks for the report! I think I see the problem.
> > 
> > Mike,
> > 
> > When you iterate over the iocb in nfs_local_call_read(), you're calling
> > nfs_local_pgio_done(), nfs_local_read_done() and
> > nfs_local_pgio_release() multiple times.
> 
> I purposely made nfs_local_pgio_done() safe to call multiple times.
> 
> And nfs_local_{read,write}_done() and nfs_local_pgio_release()
> _should_ only be called once.
> 
> >  * You're calling nfs_local_read_aio_complete() and
> >    nfs_local_read_aio_complete_work() once for each and every
> >    asynchronous call.
> 
> There is only the possibility of a single async call for the single
> aligned DIO.
> 
> For any given pgio entering LOCALIO, it may be split into 3 pieces:
> The misaligned head and tail are first handled sync and only then the
> aligned middle async (or possibly sync if underlying device imposes
> sync, e.g. ramdisk).
> 
> >  * You're calling nfs_local_pgio_done() for each synchronous call.
> 
> Yes, which is safe.  It just updates status, deals with partial
> completion.
> 
> >  * In addition, if there is a synchronous call at the very end of the
> >    iteration, so that status != -EIOCBQUEUED, then you're also calling
> >    nfs_local_read_done() one extra time, and then calling
> >    nfs_local_pgio_release().
> 
> It isn't in addition, its only for the last piece of IO (be it sync or
> async).
> 
> > The same thing appears to be happening in nfs_local_call_write().
> 
> I fully acknolwdge this isn't an easy audit.  And there could be
> something wrong.  But I'm not seeing it.  Obviously this BUG report
> puts onus on me to figure it out...
> 
> BUT, I have used this code extensively on non-debug and had no issues.
> Is it at all possible KASAN is triggering a false-positive!?

I haven't been able to reproduce this (NFS LOCALIO and KASAN is
enabled):

[root@snitzer xfstests-dev]# cat local.config
export TEST_DIR="/mnt/share1"
export TEST_DEV="10.200.111.104:/share1"
export SCRATCH_MNT="/mnt/scratch"
export SCRATCH_DEV="10.200.111.104:/"
export TEST_FS_MOUNT_OPTS="-overs=4.2,sec=sys,acl,nconnect=5"

[root@snitzer xfstests-dev]# ./check -nfs generic/323
FSTYP         -- nfs
PLATFORM      -- Linux/x86_64 snitzer 6.12.53.1.hs.snitm+ #75 SMP PREEMPT_DYNAMIC Fri Oct 17 03:55:21 UTC 2025
MKFS_OPTIONS  -- 10.200.111.104:/
MOUNT_OPTIONS -- 10.200.111.104:/ /mnt/scratch

generic/323        121s
Ran: generic/323
Passed all 1 tests

My kernel is 6.12-stable based, but includes all NFS and NFSD changes
through 6.18-rc1 (and also most of chuck's nfsd-testing), see:
https://git.kernel.org/pub/scm/linux/kernel/git/snitzer/linux.git/log/?h=kernel-6.12.53/main

Please provide your .config (off-list is fine!) and I'll see if I'm
somehow missing something.

(I suppose it could be that by test system is too slow...)

Thanks,
Mike