Fix: Fixes mount problems with Kerberos after cifs-utils update

[ks98]

Fix: Resolve mount issues with Kerberos (sec=krb5) after cifs-utils update

Problem Description

Since a recent update to the cifs-utils package, which includes the security fix for CVE-2025-2312, CIFS mounts using Kerberos authentication (sec=krb5) are failing on our Linux clients.

This manifests as the following error messages in the kernel log (dmesg):

CIFS: VFS: cifs_mount failed w/return code = -123
CIFS: Status code returned 0xc000006d NT_STATUS_LOGON_FAILURE
CIFS: Send error in SessSetup = -123

The mount command, which is executed in the background upon login, fails.

Root Cause Analysis

The issue is caused by an unfortunate interaction between the default behavior of Kerberos and a deliberate change in cifs-utils:

1. Kerberos: By default, newer versions of Kerberos create a credential cache with a random suffix (e.g., /tmp/krb5cc_215604408_aBcXyZ) to avoid collisions between multiple concurrent sessions. This behavior has existed for some time but was previously tolerated by cifs-utils.

2. cifs-utils (post-CVE-2025-2312): To address a security vulnerability, the cifs.upcall helper program was hardened. The previous "smart" behavior of scanning the /tmp directory for matching cache files (krb5cc_<UID>*) has been removed. cifs.upcall now strictly and exclusively looks for the fixed path without a suffix (e.g., FILE:/tmp/krb5cc_215604408).

Conclusion: Kerberos creates a cache with a suffix, but cifs.upcall looks for one without. As a result, the cache is not found, and authentication fails.

The Solution

This PR fixes the issue by adjusting the Kerberos configuration (/etc/krb5.conf). This instructs Kerberos to revert to using a fixed cache path without a suffix, which matches the expectations of the hardened cifs.upcall.

The following configuration is added to the [libdefaults] section of /etc/krb5.conf:

[libdefaults]
    default_ccache_name = FILE:/tmp/krb5cc_%{uid}

Considerations and Rationale

This solution deliberately restores an older Kerberos behavior. This is a pragmatic compromise, as it is currently the only reliable method to ensure compatibility with the security-hardened cifs-utils package.

The disadvantage of this approach (the risk of cache collisions with several simultaneous sessions of the same user) can be neglected for the typical use case of a desktop client in my opinion. In this context, restoring the functionality of Kerberos mounts has higher priority.

[dorianim]

Thank you for the detailed description.
I don't have any time to properly look into this until presumably mid-August.
@kiarn what do you think?

[kiarn]

Hi @ks98 and @dorianim,

I really appreciate such a PR with all explanations, many thanks for your effort @ks98 !
I personally thinks that this solution is a good compromise for us, but I didn't find time yet to test it, I must test it first.

[kiarn]

Hi @ks98

Sorry for the long delay ... I tried on my test system and I can not reproduce the problem:

$ cat /etc/issue
Ubuntu 24.04.2 LTS
$ klist 
Ticket cache: FILE:/tmp/krb5cc_259601144_iQ7eSR
Default principal: frayka@...
$ dpkg -l | grep cifs 
ii  cifs-utils                                    2:7.0-2ubuntu0.2
$ mount | grep krb5
//server/sysvol on /srv/samba/CLIENT1$/sysvol type cifs (rw,nosuid,nodev,relatime,vers=3.0,sec=krb5,cruid=0,cache=strict,upcall_target=app,username=CLIENT1$,domain=LMN.LAN,uid=0,noforceuid,gid=0,noforcegid,addr=10.0.0.1,file_mode=0700,dir_mode=0700,soft,nounix,serverino,mapposix,nobrl,mfsymlinks,rsize=4194304,wsize=4194304,bsize=1048576,retrans=1,echo_interval=60,actimeo=1,closetimeo=1)
//lmn/default-school/students/10a/frayka on /home/frayka/media/frayka (H:) type cifs (rw,nosuid,nodev,relatime,vers=3.0,sec=krb5,cruid=259601144,cache=strict,upcall_target=app,username=frayka,domain=LMN.LAN,uid=259601144,forceuid,gid=259600513,forcegid,addr=10.0.0.1,file_mode=0700,dir_mode=0700,soft,nounix,serverino,mapposix,nobrl,mfsymlinks,rsize=4194304,wsize=4194304,bsize=1048576,retrans=1,echo_interval=60,actimeo=1,closetimeo=1)
//server/sysvol on /srv/samba/frayka/sysvol type cifs (rw,nosuid,nodev,relatime,vers=3.0,sec=krb5,cruid=259601144,cache=strict,upcall_target=app,username=frayka,domain=LMN.LAN,uid=259601144,forceuid,gid=259600513,forcegid,addr=10.0.0.1,file_mode=0700,dir_mode=0700,soft,nounix,serverino,mapposix,nobrl,mfsymlinks,rsize=4194304,wsize=4194304,bsize=1048576,retrans=1,echo_interval=60,actimeo=1,closetimeo=1)
//lmn/default-school/program on /home/frayka/media/Programs (K:) type cifs (rw,nosuid,nodev,relatime,vers=3.0,sec=krb5,cruid=259601144,cache=strict,upcall_target=app,username=frayka,domain=LMN.LAN,uid=259601144,forceuid,gid=259600513,forcegid,addr=10.0.0.1,file_mode=0700,dir_mode=0700,soft,nounix,serverino,mapposix,nobrl,mfsymlinks,rsize=4194304,wsize=4194304,bsize=1048576,retrans=1,echo_interval=60,actimeo=1,closetimeo=1)
//lmn/default-school/share/projects on /home/frayka/media/Projects (P:) type cifs (rw,nosuid,nodev,relatime,vers=3.0,sec=krb5,cruid=259601144,cache=strict,upcall_target=app,username=frayka,domain=LMN.LAN,uid=259601144,forceuid,gid=259600513,forcegid,addr=10.0.0.1,file_mode=0700,dir_mode=0700,soft,nounix,serverino,mapposix,nobrl,mfsymlinks,rsize=4194304,wsize=4194304,bsize=1048576,retrans=1,echo_interval=60,actimeo=1,closetimeo=1)
//lmn/default-school/share on /home/frayka/media/Shares (T:) type cifs (rw,nosuid,nodev,relatime,vers=3.0,sec=krb5,cruid=259601144,cache=strict,upcall_target=app,username=frayka,domain=LMN.LAN,uid=259601144,forceuid,gid=259600513,forcegid,addr=10.0.0.1,file_mode=0700,dir_mode=0700,soft,nounix,serverino,mapposix,nobrl,mfsymlinks,rsize=4194304,wsize=4194304,bsize=1048576,retrans=1,echo_interval=60,actimeo=1,closetimeo=1)

So, the client (Ubuntu Noble) doesn't seem to have problem to mount the shares with the krb5 option, even if the ticket has a random location. It would be interesting to understand the differences between your installation and mine, in order to isolate the origin of the problem. Or did I miss something ?

Looking at the errno.h errors codes, depending on your kernel, it could be various reasons like:

• accessing a corrupted shared library
• no medium found
• ...

Maybe it could be hint to understand what is going on ?

Regards

Arnaud

[dorianim]

@HappyBasher please explain your reasoning for merging! Were you able to reproduce it? How?

[HappyBasher]

I reproduced it on a Debian 12 client with a lmn 7.3 server, which was not able to login until default_ccache_name was set as mentioned.

[kiarn]

It works for me too on a 24.04 client, so I don't see any breaking change.