o3_finds_CVE-2025-37778.txt

Vulnerability: use‑after‑free of sess->user during failed re‑authentication (SMB2 SESSION_SETUP / Kerberos)

-----------------------------------------------------------------
1.  Entry point  
    smb2_sess_setup()  (kernel/fs/smb/server/smb2pdu.c)

2.  Preconditions an attacker can meet  
    • A first (successful) SMB 3.11/Kerberos log‑in has created a
      ksmbd_session object whose state is SMB2_SESSION_VALID.  
    • The attacker now sends a second SESSION_SETUP request on the
      same session (reauthentication).  
      This is completely legal in SMB and is handled in the
      “krb5_authenticate()” path.

3.  Code path to the bug

   smb2_sess_setup()
   └── krb5_authenticate(work, req, rsp)                   (same file)
       ├─ sees  sess->state == SMB2_SESSION_VALID
       │   → ksmbd_free_user(sess->user);      /* FREE #1 */
       │     /*  sess->user is now a dangling pointer,
       │        it is NOT set to NULL              */
       │
       ├─ allocates a new user object
       │   user = ksmbd_alloc_user(...);
       │
       └─ … any error that makes ‘user’ stay NULL or makes the
          function jump to “out:” will return < 0 to the caller
          (examples: kmalloc failure, user‑space helper error,
          excessively large session key, etc.)

   smb2_sess_setup()    (back from krb5_authenticate with rc < 0)
   └── out_err:                                            (line ≈ 2140)
       if (sess) {
           bool try_delay = false;

           /* USE #1 – dereference after the free */  
           if (sess->user && sess->user->flags & KSMBD_USER_FLAG_DELAY_SESSION)
                   try_delay = true;
           …
           ksmbd_user_session_put(sess);    /* may drop the last ref
                                               and free ‘sess’ as well */
           work->sess = NULL;
       }

4.  Result  
   sess->user was freed in krb5_authenticate() but is dereferenced
   afterwards in smb2_sess_setup().  This is a classic
   use‑after‑free (read) in kernel context.

   The freed slab object is of type ‘struct ksmbd_user’; its first
   member is the 16‑bit “flags” field that is read again.  An
   attacker can try to re‑allocate that slab (e.g. by spraying
   kmalloc‑64 objects) and control the value that is read, or
   trigger a kernel fault if the address is unmapped.

5.  How the attacker controls the branch  

   • He already owns a valid, signed‑in session (step 2).  
   • He sends a new SESSION_SETUP using the same session id and
     Kerberos security blob.  
   • He provokes any failure inside krb5_authenticate() after the
     original user was freed:  
       – cause kmalloc to fail (memory pressure); or  
       – make the user‑space helper return an error (e.g. bad
         credentials) so that ksmbd_alloc_user() is never reached or
         returns NULL.  
   • The function unwinds through the buggy path and hits the
     dangling pointer.

6.  Proof‑of‑concept outline (one possible way)

   a) establish a normal Kerberos session.  
   b) exhaust kmalloc‑128 cache from another CPU (to increase
      failure probability).  
   c) send second SESSION_SETUP for the same session id.  
   d) when ksmbd_alloc_user() fails, the freed ‘struct ksmbd_user’
      slot can already be re‑allocated by the spray, so the kernel
      reads attacker‑controlled data.

7.  Fix suggestion

   In krb5_authenticate():

       if (sess->state == SMB2_SESSION_VALID) {
           ksmbd_free_user(sess->user);
           sess->user = NULL;      /* <- add this */
       }

   or even better, postpone freeing the old user until the new
   ksmbd_alloc_user() succeeds.

   The same pattern should be audited in other authentication
   helpers (NTLM, etc.) to avoid similar bugs.

-----------------------------------------------------------------
I did not find other use‑after‑free issues in the smb2_sess_setup
call chain; the above is the only concrete vulnerability identified
in this audit.