CVE-2025-21964 - Integer Overflow in Linux Kernel CIFS acregmax Handling

Recently, a critical vulnerability was identified and patched in the Linux kernel's CIFS file system relating to the handling of the acregmax mount option. Tracked as CVE-2025-21964, this bug could allow an attacker to cause integer overflows leading to unstable or dangerous system behavior. The bug was discovered by Linux Verification Center using their SVACE static analysis tool.

This post will walk you through the vulnerability, how it works, how it was fixed, and what steps you should take to keep your system secure.

What is CIFS and acregmax?

CIFS (Common Internet File System) is a network file-sharing protocol used in Linux for mounting and using SMB (Server Message Block) shares (commonly used for file sharing with Windows systems).

acregmax is a mount option that controls how long the file attribute cache can remain valid for regular files. It's set in seconds and is supposed to have an upper bound to prevent absurdly large values.

Type confusion: The value is parsed as a 32-bit unsigned integer (u32) in seconds.

- Premature conversion: Before validating if acregmax is within a safe range, it gets multiplied by HZ (Linux "jiffies per second", typically 100 or 100)—this can cause an integer overflow.
- Consequences: If a very large value is provided, the conversion can wrap around or overflow, causing negative cache durations or undefined behavior. This can destabilize the kernel or produce unexpected side effects.

Here's a simplified version of what was happening in the CIFS kernel code (fs/cifs/connect.c)

// Mount parameter 'acregmax' is provided by the user
unsigned int acregmax; // seconds

// Existing buggy code
acregmax = simple_strtoul(option_value, NULL, ); // get from mount string

// Convert seconds -> jiffies BEFORE validating (problem!)
acregmax = acregmax * HZ;

// Now, upper-limit validation (too late!)
if (acregmax > CIFS_ACREGMAX_MAX)
    acregmax = CIFS_ACREGMAX_MAX;

By providing a huge value (like xffffffff), the multiplication can wrap the integer variable.

How Was it Fixed?

The fix ensures that the user-provided acregmax value is validated before converting it to jiffies. Check the patch on kernel.org:

Fixed code

unsigned int acregmax = simple_strtoul(option_value, NULL, );

// Validate upper limit first!
if (acregmax > CIFS_ACREGMAX_MAX_SECONDS)
    acregmax = CIFS_ACREGMAX_MAX_SECONDS;

// Now convert to jiffies, safe from overflow
acregmax = acregmax * HZ;

How Can This Be Exploited?

A user with the ability to mount SMB/CIFS shares (local user or potentially via misconfigured automated scripts) could supply a crafted acregmax argument to the kernel.

For instance

mount -t cifs //server/share /mnt -o user=foo,password=bar,acregmax=4294967295

Mount command with large acregmax

mount -t cifs //server/share /mnt/point \
 -o username=test,password=test,acregmax=4294967295

Check system logs (dmesg or /var/log/messages) for kernel warnings or errors after the mount—with a vulnerable kernel, you might see complaints about invalid cache times, or the kernel might stabilize after forcibly correcting the value.

Safe if

- You're running a kernel with the patch above (kernel version TBD at disclosure, check your distribution security advisories).

Original Patch:

cifs: Fix integer overflow while processing acregmax mount option

Linux Verification Center (SVACE):

https://linuxtesting.org/projects/svace/
- CIFS kernel documentation
- CVE-2025-21964 MITRE Entry (pending)

Check audit logs for suspicious mount requests.

For system administrators, consider limiting who can mount network filesystems or using tools like mount.cifs with a restricted sudoers configuration.

Conclusion

CVE-2025-21964 highlights the importance of carefully validating user-provided input—before any conversion or calculation is performed. While this bug is now fixed, please be diligent about keeping your systems updated and reviewing security announcements for components like the Linux kernel CIFS driver.

Have questions or want to share your experience? Drop a comment or reach out on the kernel mailing list!

Timeline

Published on: 04/01/2025 16:15:27 UTC
Last modified on: 05/04/2025 07:25:54 UTC