Another local privilege escalation. This one has been hiding since 2007.

In my Dirty Frag post, I wrote that we expected vulnerabilities to come in waves. In Fragnesia, we proved it by going out and finding one ourselves. What I didn't predict was that the next wave would reach back to 2007.

CIFSwitch is the start of another wave. It's a different class of vulnerability, a trust-boundary violation, and the pattern is the same: one disclosure trains researchers and AI agents to look for adjacent code with the same shape.

On May 27, security researcher Asim Manizada publicly disclosed CIFSwitch in the Linux kernel's CIFS client and the cifs-utils userspace helper. No CVE has been assigned yet. Unlike Fragnesia, which dropped without any embargo or coordination, the community was notified here and coordination happened in advance, which accelerated patching. That's how it's supposed to work.

The short version: the kernel asks a root-running helper to authenticate SMB connections, and nothing stops an unprivileged user from making that same request with attacker-controlled arguments. The helper trusts them.

Here's the mechanism. Most distros ship /etc/request-key.d/cifs.spnego.conf with a rule that fires cifs.upcall as root whenever the kernel asks for a cifs.spnego key. The userland helper is meant to be invoked only by the kernel CIFS client during SMB authentication. However, request_key("cifs.spnego", description, ...) is callable from unprivileged userspace. The kernel hands the request to userland cifs.upcall running as root but never validates that the request actually originated from the kernel CIFS client.

A user could craft any description, including the helper's own argument flags like upcall_target=app baked into it and cifs.upcall trusts those attacker-supplied fields (pid, uid, creduid, upcall_target) as if they'd come from the kernel CIFS client. With upcall_target=app it switches into the namespace with the exploit payload. As root, cifs.upcall does name-service lookups (getpwuid / getgrgid). NSS reads /etc/nsswitch.conf and then dlopen()s libnss_<module>.so.2. Inside the attacker's namespace, both files are attacker-controlled. The shared object's constructor runs as root.

What stands out is the age. The vulnerable code path has existed since the cifs.spnego key type landed in 2007. It has survived multiple kernel releases, several rewrites of nearby code, and the entire shift to namespaced containers. The fix is a small kernel patch ("smb: client: reject userspace cifs.spnego descriptions") that validates the current credentials against the spnego_cred.

The researcher credits LLM-assisted graph reasoning for finding the vulnerability, which is exactly the pattern I described in the Dirty Frag post: AI scanning large codebases, recognizing structural patterns, surfacing bugs humans had walked past for years. This is what that wave looks like from the inside. I expect we will see more trust-boundary violations surface in the near future.

For CIFSwitch specifically, the kernel patch is in flight to stable and the cifs-utils maintainers are working on userspace hardening. Patched kernels are rolling through CIQ's test and release process as we publish this. If you're running Rocky Linux or an RLC Pro variant, the KB article linked below has four mitigation options you can apply today, including a request-key override that doesn't require unloading kernel modules or rebooting. The KB also tracks patched kernel availability per variant as it rolls out.

Trust-boundary violations are a different shape than page-cache LPEs, but the AI-assisted discovery mechanism is the same. We'll be watching for the next one.

Check out the CIFSwitch KB article for current patch status and all four mitigation options.