Unpatched Linux Kernel Keyring Flaw Gives Local Root

A public exploit chain can turn an unprivileged Linux user into root by abusing the kernel’s keyring code, and the fix has not yet reached the mainline kernel.

The flaw sits in lib/assoc_array.c, the kernel’s associative-array data structure, which the keyrings subsystem under security/keys/ uses to store keys. A single add_key operation can place one shortcut node directly behind another in a keyring’s tree — a state the code assumes can never happen — leaving a reader walking the broken tree onto an object it wrongly trusts as a kernel key. No CVE has been assigned as of November 15, 2026.

Security researcher Daniel Wade published a working exploit for the bug on GitHub on November 15, after discovering the publicly known flaw while preparing for Google’s kernelCTF competition. The bug reaches back to 3cb989501c26, the commit that added the generic associative-array implementation around 2013.

A fix exists — Linus Torvalds wrote one and committed it to a kernel tree on October 13 — but it is not in the mainline kernel. A check of the torvalds/linux master branch on November 15 shows the vulnerable code still in place, meaning no stable kernel and no Linux distribution has shipped a corrected build.

How the assoc_array Keyring Flaw Works

The associative array in lib/assoc_array.c is an RCU-safe radix tree built from 16-slot nodes and shortcuts, where a shortcut compresses a single-occupant branch into one hop and stores the skipped index bits inline. The structure’s design guarantees that a shortcut’s parent is always a node, never another shortcut, because the first shortcut would have absorbed the second’s bits.

According to Torvalds’ fix commit, deletion can break that guarantee. When the subtree below a shortcut shrinks sufficiently, the delete path collapses it into a single node beneath the shortcut. A later insertion whose keys all share that node’s segment then replaces the node with a new shortcut — and installs the new shortcut behind the existing one.

That shortcut-behind-a-shortcut arrangement is what nothing in the code expects. The tree walker, assoc_array_walk(), indexes the second shortcut as if it were a node and mis-parses the skipped bits, so a reader follows a pointer from the wrong level of the tree. On the same insertion, assoc_array_apply_edit() trips the BUG_ON() check that normally guards this condition. Torvalds’ commit message describes the minimal trigger as eighteen insertions and a deletion: sixteen keys that agree on bits 0-11, one that diverges at bit 8 and is then deleted, and one more that rejoins the sixteen.

The fix makes the new shortcut replace the old one in front of the node as well, which required a second slot in the kernel’s excised_meta[] tracking array. Torvalds credited Nils Ollrogge as the reporter and David Howells as tester and reviewer, and the commit carries an Assisted-by: LLM trailer. The same function, assoc_array_insert_into_terminal_node(), was behind two earlier denial-of-service bugs, CVE-2016-7914 and CVE-2017-12193.

How the Bug Escalates to Root

On its own, the bug crashes the thread that triggers it. The published exploit arranges for a second thread to be reading the keyring at the moment of the crash, so it survives and processes the corrupted tree, treating an attacker-controlled allocation as a kernel key structure.

The kernel’s own per-user key-quota accounting then writes through that aliased object into a process’s credential fields.

Wade describes the result as a capability escalation rather than a direct user-ID change: the process keeps its original UID but gains a full effective capability set, including CAP_DAC_OVERRIDE, which overrides file read permissions. From there the exploit uses CAP_SETUID to call setresuid(0,0,0) and exec a shell, at which point the kernel grants full root privileges through the normal path. The attack needs only a local unprivileged account, with no capabilities and no user namespaces.

Is the assoc_array Flaw Being Exploited?

There are no reports of this flaw being exploited in the wild, and with no CVE assigned, it does not appear in CISA’s Known Exploited Vulnerabilities catalog. The public exploit is the main exposure. Wade’s repository ships a prebuilt binary and source, but he describes it as a lab artifact built against a pinned image — Google’s hardened kernelCTF 7.2-rc5 target — and says that running the full chain requires that matching image and a kernelCTF-style initramfs, neither of which is included.

The exploit is a heap race, and Wade reports it is not fully reliable even on his own target: he cites a 7-of-8 success rate for the root-shell build and 14-of-20 for a flag-read variant on a two-vCPU virtual machine. Cyber Kendra could not independently verify those figures, which are based on the researcher’s own testing against a single kernel build. Wade also notes the exploit was public before he could have used it competitively and says it would not have scored well in kernelCTF.

Which Kernels and Distributions Are Affected

Because the bug lies in the original associative-array implementation, every kernel that carries that code is affected in principle, though the public exploit is written and tuned for a single hardened build. As of November 15, 2026, the only fix is the commit in Torvalds’ tree; it has not been merged to mainline, no stable or long-term kernel carries it, and no distribution has issued an advisory.

What Linux Admins Should Do Now

No distribution kernel update is available yet, so the immediate step is to track the fix rather than install it. Administrators who build their own kernels can apply the commit 48691075b0ad or wait for it to land in mainline and flow into stable releases; the vulnerable code is identifiable by the single-entry excised_meta[1] array in include/linux/assoc_array_priv.h, which the fix expands to [2].

For hardening in the meantime, Wade states that restricting unprivileged access to the AF_ALG socket interface removes the heap-grooming oracle his exploit chain depends on. That measure is the researcher’s recommendation, not a vendor-published workaround, and the broader keyring attack surface remains reachable by any local user until a patched kernel ships. Running the standard check — uname -r — will show the kernel version, but no fixed build number exists to compare it against yet.