CVE-2026-31392

In the Linux kernel, the following vulnerability has been resolved:

smb: client: fix krb5 mount with username option

Customer reported that some of their krb5 mounts were failing against

a single server as the client was trying to mount the shares with

wrong credentials. It turned out the client was reusing SMB session

from first mount to try mounting the other shares, even though a

different username= option had been specified to the other mounts.

By using username mount option along with sec=krb5 to search for

principals from keytab is supported by cifs.upcall(8) since

cifs-utils-4.8. So fix this by matching username mount option in

match_session() even with Kerberos.

For example, the second mount below should fail with -ENOKEY as there

is no 'foobar' principal in keytab (/etc/krb5.keytab). The client

ends up reusing SMB session from first mount to perform the second

one, which is wrong.

```

$ ktutil

ktutil: add_entry -password -p testuser -k 1 -e aes256-cts

Password for [email protected]:

ktutil: write_kt /etc/krb5.keytab

ktutil: quit

$ klist -ke

Keytab name: FILE:/etc/krb5.keytab

KVNO Principal

---- ----------------------------------------------------------------

1 [email protected] (aes256-cts-hmac-sha1-96)

$ mount.cifs //w22-root2/scratch /mnt/1 -o sec=krb5,username=testuser

$ mount.cifs //w22-root2/scratch /mnt/2 -o sec=krb5,username=foobar

$ mount -t cifs | grep -Po 'username=\K\w+'

testuser

testuser

```