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

> 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
>