Re: ksmbd: BUG_ON in locks_release_private() - file_lock destroyed while VFS blocked requests are still attached

Could you confirm whether you can reproduce it on `ksmbd-for-next-next` 
branch?
https://github.com/smfrench/smb3-kernel/commits/ksmbd-for-next-next

On 8/13/26 16:23, Blue bird wrote:
> Thanks for confirming it on mainline.
> 
> One thing about the for-next-next run: the output shows locks_sent=0,
> which means the harness never managed to send a single lock request, so
> that run did not exercise the path at all. It is not evidence that the
> branch is unaffected. The harness silently retries on connection errors,
> which makes a failed setup look like a clean run -- sorry about that.
> 
> kfuzz2.py defaults to:
> 
>      KFUZZ_HOST=127.0.0.1  KFUZZ_USER=fuzzuser
>      KFUZZ_PASS=fuzzpass   KFUZZ_SHARE=fuzz
> 
> so it needs a share named "fuzz" and that user to exist. Please set those
> to match your setup and check that locks_sent climbs before drawing a
> conclusion.
> 
> On the UAF you hit: I think it may be the same one I have now root-caused.
> Captured on a clean untainted mainline boot with continuous logging
> (ksmbd's own log spam overflows the ring buffer and hides the earlier
> faults, which is why I missed the ordering at first):
> 
>    [284.826] BUG: KASAN: slab-use-after-free in smb2_lock+0x33b4
>              Write of size 8 by task 1984
>              Allocated by task 1984: smb2_lock+0xa90
>              Freed by task 2119:     smb2_lock+0x23b4
>    [285.088] same task -> _raw_spin_lock on garbage -> Oops
>    [287.598] kernel BUG at fs/locks.c:312
> 
> Symbolized:
>    alloc +0xa90  ->smb2pdu.c:8156  smb2_lock_init()
>    free  +0x23b4 ->smb2pdu.c:8213  the cross-request unlock kfree(cmp_lock)
>    write +0x33b4 ->smb2pdu.c:8323  list_del(&smb_lock->llist),
>                     inlinedlist.h:260 == next->prev = prev
> 
> struct ksmbd_lock is on three lists: clist (conn->lock_list), flist
> (fp->lock_list) and llist (the*on-stack* lock_list / rollback_list of the
> request that created it). The cross-request unlock path removes flist and
> clist but not llist, so one worker frees an object that another worker
> still has threaded onto its stack-resident list; that worker then wakes
> from ksmbd_vfs_posix_lock_wait() and list_del() writes through the freed
> neighbour.
> 
> Note this UAF is the*first* fault, on an untainted kernel -- it precedes
> the BUG_ON rather than being fallout from it, and it is a write, not a read.
> 
> Also, please do not treat my earlier vfs_cache.c hunk as a fix. With it
> applied the BUG_ON still reproduces in ~5 s; the trace just moves from
> __ksmbd_close_fd() to smb2_lock+0x23ac, i.e.smb2pdu.c:8213 -- the same
> cross-request unlock path above, which that patch does not touch.

-- 
ChenXiaoSong <[email protected]>
Chinese Homepage: https://chenxiaosong.com
English Homepage: https://chenxiaosong.com/en