The Linux kernel, being the backbone of most modern servers, desktops, and embedded systems, is no stranger to security vulnerabilities. In this post, we shed light on CVE-2025-21672, a kernel bug that was recently patched concerning the AFS (Andrew File System) filesystem implementation. This issue was flagged by syzbot, a kernel bug detection robot, and relates to a missing lock release under certain error conditions—potentially causing deadlocks or security issues.

We’ll explain the nature of the bug, provide code snippets, describe its exploitation potential, and reference the original sources. Whether you’re a sysadmin, developer, or just a security enthusiast, here’s an exclusive and easy-to-follow breakdown.

What Happened?

Within the Linux kernel's AFS code, there’s a function handling address preference settings:
afs_proc_addr_prefs_write()
When it encounters malformed user input, it may return early without releasing an inode lock, leading to kernel warnings and faulty behavior.

Here’s an extract from the syzbot report

WARNING: lock held when returning to user space!
syz-executor133/5823 is leaving the kernel with locks still held!
1 lock held by syz-executor133/5823:
 #: ffff888071cffc00 (&sb->s_type->i_mutex_key#9){++++}-{4:4}, at: afs_proc_addr_prefs_write+...

This means a lock was acquired but never released. If enough of these accumulate, system health degrades, or hangs can result.

Before the patch, the function looked roughly like this (simplified for clarity)

int afs_proc_addr_prefs_write(struct file *file, const char __user *buffer, size_t count, loff_t *ppos)
{
    /* ...snip... */
    inode_lock(inode);
    argc = afs_split_string(...);
    if (argc < )
        return argc;     // <-- Bug: Returns with lock held!
    /* ... further code ... */
    inode_unlock(inode);
}

Here, if afs_split_string() returns a negative (error) value, the function exits *without* releasing the inode lock—a classic slip.

The Patch (Fix)

The fix is elegantly simple: Jump to unlock-and-return code on all exits. The error code is stored and cleanup is performed through a single code path.

Patched snippet

int afs_proc_addr_prefs_write(struct file *file, const char __user *buffer, size_t count, loff_t *ppos)
{
    int ret = , argc;
    /* ...snip... */
    inode_lock(inode);
    argc = afs_split_string(...);
    if (argc < ) {
        ret = argc;
        goto done;       // Jump to cleanup!
    }
    /* ... */
done:
    inode_unlock(inode);
    return ret;
}

With this, locks are always released regardless of the path taken—even on errors.

How Could It Be Exploited?

While this bug doesn't allow a direct privilege escalation, local users *can* cause the process to hold onto locks longer than it should, potentially leading to:

Denial of service (DoS)

A malicious user could, for example, repeatedly supply malformed input to trigger the error path and degrade system stability.

A simple reproduction might look like

echo "malformed input here" > /proc/fs/afs/cell/addr_prefs
# If malformed, triggers the lock leak

Normally, regular users may not have write access to these files, but the risk is more critical for systems where unprivileged write access is possible due to misconfiguration.

Original syzbot report:

syzbot link
*(Exact link may vary. For kernel developers, see the Linux kernel mailing list or the syzbot dashboard.)*

Linux Kernel Git Patch:

afs: Fix merge preference rule failure condition (git.kernel.org)

Syzbot: Kernel Fuzzing

syzkaller project

Conclusion

CVE-2025-21672 is another case of a seemingly minor kernel logic error escalating into potential stability and security headaches. Thanks to continuous fuzz-testing by syzbot, such bugs are found and fixed quickly.

If your systems rely on AFS or similarly rare filesystems, don’t wait—apply the patch and keep your infrastructure secure!


*Stay tuned for more exclusive Linux vulnerability insights!*

Timeline

Published on: 01/31/2025 12:15:28 UTC
Last modified on: 02/03/2025 20:04:22 UTC