CVE-2026-31392

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: client: fix krb5 mount with username option<br /> <br /> Customer reported that some of their krb5 mounts were failing against<br /> a single server as the client was trying to mount the shares with<br /> wrong credentials. It turned out the client was reusing SMB session<br /> from first mount to try mounting the other shares, even though a<br /> different username= option had been specified to the other mounts.<br /> <br /> By using username mount option along with sec=krb5 to search for<br /> principals from keytab is supported by cifs.upcall(8) since<br /> cifs-utils-4.8. So fix this by matching username mount option in<br /> match_session() even with Kerberos.<br /> <br /> For example, the second mount below should fail with -ENOKEY as there<br /> is no &amp;#39;foobar&amp;#39; principal in keytab (/etc/krb5.keytab). The client<br /> ends up reusing SMB session from first mount to perform the second<br /> one, which is wrong.<br /> <br /> ```<br /> $ ktutil<br /> ktutil: add_entry -password -p testuser -k 1 -e aes256-cts<br /> Password for testuser@ZELDA.TEST:<br /> ktutil: write_kt /etc/krb5.keytab<br /> ktutil: quit<br /> $ klist -ke<br /> Keytab name: FILE:/etc/krb5.keytab<br /> KVNO Principal<br /> ---- ----------------------------------------------------------------<br /> 1 testuser@ZELDA.TEST (aes256-cts-hmac-sha1-96)<br /> $ mount.cifs //w22-root2/scratch /mnt/1 -o sec=krb5,username=testuser<br /> $ mount.cifs //w22-root2/scratch /mnt/2 -o sec=krb5,username=foobar<br /> $ mount -t cifs | grep -Po &amp;#39;username=\K\w+&amp;#39;<br /> testuser<br /> testuser<br /> ```