CIFSwitch: a non-universal Linux local root vulnerability · Hey, it's Asim
↓<br>Skip to main content
Hey, it’s Asim
Table of Contents
Table of Contents
TLDR: A distro-specific Linux LPE found by harnessing LLMs into better multihop knowledge composition. Read on for affected distros, mitigations, and vulnerability details.
Background
In Getting LLMs Drunk to Find Remote Linux Kernel OOB<br>Writes (and More),<br>I’d mentioned how improving LLMs’ ability to compose existing knowledge is a promising avenue for unlocking<br>“creative” – or at least non-trivial – vulnerability findings. Incidentally, among the latest slew of Linux LPEs,<br>CopyFail stood out for – among other things – exquisitely composing several logic bugs,<br>serving as a reminder of the massive potential value of the approach. Unfortunately, training a capable looped<br>transformer to improve compositionality was a non-starter, so I started looking for harness-level improvements instead.
GraphWalk: Enabling<br>Reasoning in Large Language Models through Tool-Based Graph<br>Navigation offered a promising alternative: the authors<br>developed a tool for models to traverse (and reason through) graphs, improving their multihop reasoning capabilities.<br>The benefits were measured primarily for non-reasoning models; but, on large-enough graphs, non-reasoning models equipped with the tool outperformed<br>reasoning models without it. So, the general approach seemed promising even for otherwise-scaffolded reasoning models – slicing the context with RLMs, .md files with “memories,” etc., are all useful for tackling graph-based<br>problems, but we could still strengthen the harness with a first-class graph traversal tool.
The paper described a tool for existing graphs, but for vulnerability hunting we don’t actually have<br>“interesting” graphs pre-built (CodeQL-style CPGs are too low-level/clunky for the level of abstraction I wanted)!<br>So I harnessed the agents to a) build the graphs at a higher level of abstraction and b) actually query them,<br>like in the paper above.<br>The graphs were intended to capture the following (deliberately somewhat fuzzy to play to LLMs’ strengths):
Privileged consumers: what kernel paths, daemons, helpers, etc. consume an object as authoritative?
Creators: what actions create or modify (in some way) the object? Are they attacker-controlled? Under what conditions?
Object: what is the exact kernel object – e.g. key, policy verdict, fd, queue entry, signature, etc.?
Check split: what security-relevant properties of the object are checked at creation time vs. later?
Drift: (the most important) how can an object’s origin, credentials, namespace, idmap, mount view, LSM domain, etc. stop matching what’s assumed by its consumer?
At this point, I had the scaffolding to point at the desired target. Ideally, it’d be something<br>straddling kernel and userspace for compositionality to really shine, and primarily/entirely a logic bug chain…<br>Based on some<br>prior<br>experience, the SMB protocol<br>family seemed like a fertile ground.
The vulnerability
The harnessed agents found an issue at the intersection of kernel’s CIFS<br>and the userspace cifs-utils-provided helper.
In short, they first discovered that<br>the kernel did not validate the description origin of the cifs.spnego key object. Backtracking, they<br>then found that they could therefore issue a request_key() syscall with a fake key description, which<br>launches a rootful helper. Finally, after noticing that the fake key descriptions have actual security<br>relevance – they contain pid, which combined with upcall_target=app controls which namespace the<br>helper actually runs in – they converted the namespace confusion into root on the machine.
Since the patch has been out for over a week<br>and is queued for stable, we agreed with linux-distros@ on an embargo through May 27, 2026. The advisory is now public so that<br>the affected system owners can patch or apply other mitigations. The CVE assignment is still pending.
CIFS basics
CIFS/SMB is a Windows-style network filesystem protocol. On Linux, the CIFS kernel<br>client handles the actual filesystem parts: mounting the share, talking SMB to the server,<br>doing reads/writes, etc. But, understandably, for Kerberos-auth’d mounts, kernel CIFS<br>doesn’t roll its own auth stack and instead relies on a userspace helper provided by cifs-utils.
The interaction happens through Linux keyrings. The kernel requests a cifs.spnego-type key,<br>and the normal keyutils/request-key config runs cifs.upcall as root to<br>fetch or build the Kerberos/SPNEGO material. That brings us to – ahem – the key part.
Bird’s eye view
The expected interaction between the kernel and userspace parts is the following:
Kernel CIFS decides it needs Kerberos/SPNEGO material for a mount.
Kernel CIFS builds a semicolon-separated cifs.spnego description string from real kernel state: server, uid, creduid, pid,...