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

Should this carry a Fixes: tag so it gets picked up for stable?

2026년 8월 13일 (목) 오후 8:03, Blue bird <[email protected]>님이 작성:
>
> > The UAF issue is reproducible every time, and I have already submitted a
> > patch to fix it:
> > https://lore.kernel.org/linux-cifs/[email protected]/
>
> Thanks for the patch and for the credit -- but I think that is a different bug
> from the one I reported, and the fs/locks.c:312 BUG_ON is still open.
>
> Your patch fixes a proc_dir_entry use-after-free in
> ksmbd_conn_transport_destroy() on module unload. Mine is a BUG_ON in
> __ksmbd_close_fd() on connection teardown, from a byte-range lock whose
> file_lock still has blocked requests chained onto it. Different file, different
> path, and the reproducer for yours is mount/umount/modprobe -r rather than lock
> traffic.
>
>
> Your "cannot reproduce on ksmbd-for-next-next" run sent no lock requests
> -----------------------------------------------------------------------
>
> From your earlier mail:
>
> >  LF_SECONDS=10 python3 -u lockfuzz2.py
> >  t=5s locks_sent=0 faults=0
> >  t=10s locks_sent=0 faults=0
>
> locks_sent=0 means the harness never got a single LOCK onto the wire, so that
> run cannot tell us anything about whether the bug is fixed. It is the failure
> mode I described in my previous mail -- sorry, our mails crossed.
>
> Two things on ksmbd-for-next-next stop the harness silently:
>
> 1. smb2_check_sequence_number(), added by 9d597c4a23 ("ksmbd: recognize
>    replayed SMB2 lock sequences"). The harness authenticates with impacket and
>    then emits raw SMB2 PDUs, and it used to start MessageId at an arbitrary
>    value. That is now outside the connection's sequence window, so every raw
>    request is rejected with STATUS_INVALID_PARAMETER -- including the CREATE,
>    so no file is opened and no lock is ever sent.
>
>    One-line fix in kfuzz2.py, in Sess.__init__, right after connectTree():
>
>      self.tid = self.c.connectTree(SHARE)
>    - self.mid = 4096
>    + self.mid = int(s3._Connection['SequenceWindow'])
>
> 2. "max ip connections". The harness churns connections from one address and
>    hits
>
>      ksmbd: Maximum IP connections exceeded (32/32)
>
>    after which it cannot establish sessions. Add to ksmbd.conf:
>
>      [global]
>              max ip connections = 0
>
> With those two changes the harness reports a non-zero locks_sent, which is the
> thing to check before trusting a negative result.
>
>
> With that, it still reproduces on ksmbd-for-next-next
> -----------------------------------------------------
>
> Branch smb3/ksmbd-for-next-next at e7317f3e41 ("smb: server: Clear
> Preauth_HashValue in smb2pdu.c with kfree_sensitive()"), re-fetched just now to
> be sure it had not moved. fs/smb/ built from that branch against the same
> 7.2.0-rc7 it is based on; I verified the loaded module was the branch build.
> Freshly booted guest, kernel otherwise clean:
>
>   test started at uptime 120 s
>   fault at uptime 121.6 s -- about 1.6 s in, after 142 lock requests
>
>   kernel BUG at fs/locks.c:312!
>   CPU: 2 UID: 0 PID: 1575 Comm: ksmbd:::ffff:12 Tainted: G           O
>   Tainted: [O]=OOT_MODULE
>   pc : locks_release_private+0x214/0x2c8
>   Call trace:
>    locks_release_private+0x214/0x2c8 (P)
>    locks_free_lock+0x20/0x40
>    __ksmbd_close_fd+0x4d8/0xd28          [ksmbd]
>    ksmbd_destroy_file_table+0x5c/0xf4    [ksmbd]
>    ksmbd_session_destroy+0xbc/0x38c      [ksmbd]
>    ksmbd_sessions_deregister+0x450/0x540 [ksmbd]
>    ksmbd_server_terminate_conn+0x20/0x40 [ksmbd]
>
> The taint word is OOT_MODULE only, so this is the first fault on the boot, not
> fallout from something else. I have seen it three times on that branch now
> (142, 208 and ~200 lock requests), always as the first fault.
>
> I also re-ran the mixed load that produced the KASAN use-after-free on mainline
> for 500 s on this branch: zero smb2_lock use-after-frees, consistent with
> c120970353 having fixed that one. So on ksmbd-for-next-next the lock UAF is
> gone, but the fs/locks.c:312 BUG_ON is not.
>
> Happy to test any patch for it.
>
> 2026년 8월 13일 (목) 오후 7:44, ChenXiaoSong <[email protected]>님이 작성:
> >
> > The UAF issue is reproducible every time, and I have already submitted a
> > patch to fix it:
> > https://lore.kernel.org/linux-cifs/[email protected]/
> >
> > 在 2026/8/13 18:17, Blue bird 写道:
> > > Yes for the BUG_ON, no for the use-after-free. Details below, and I am inlining
> > > kfuzz2.py at the end since it never made it to the list.
> >
> > --
> > ChenXiaoSong <[email protected]>
> > Chinese Homepage: https://chenxiaosong.com
> > English Homepage: https://chenxiaosong.com/en
> >