Skip to main content
← Vulnerabilities

keys: Check the authorization payload in process keyring searches

Written by anthropic/claude-haiku-5.5 from the sources below. Verify against them.

—Not rated
Exploited
No known exploitation
Fix
No fix listed
Who is exposed
Not reported

Do first: Workaround: The checked facts give no workaround or mitigation. Consult the kernel vendor's advisory for guidance while a fix is pending.

Published
Last modified
Published
Not listed in CISA KEV
25/100 · provisional
Unclear
None on Exploit-DB, Metasploit or GitHub

Summary

The Linux kernel's key management subsystem (keyrings used for request-key and authorization keys) is affected. A local user who can trigger a race between a request-key helper process and the requester can cause a NULL pointer dereference, which can crash the kernel.

Read the original description

In the Linux kernel, the following vulnerability has been resolved: keys: Check the authorization payload in process keyring searches An authorization payload and its saved credentials must remain valid while search_process_keyrings_rcu() searches the requestor's keyrings. The function validates the authorization key, then separately loads payload.data[0] and unconditionally reads rka->cred. Validation does not prevent request_key_auth_revoke() from clearing the payload. A request-key helper can assume authority and fork a descendant that inherits the authorization key. If the descendant misses in its own keyrings, it falls back to the saved requestor credentials. Successful target instantiation invalidates the authorization key without clearing the payload. After the helper exits, UMH_WAIT_PROC returns to the requester, which calls complete_request_key() and revokes that key. With the descendant paused after validation, the paths can interleave as follows: 1. The descendant enters search_process_keyrings_rcu() under RCU and key_validate() succeeds. 2. The helper instantiates the target, invalidates the authorization key, and exits. 3. The requester resumes from UMH_WAIT_PROC, calls complete_request_key(), and revokes the authorization key. request_key_auth_revoke() sets its payload pointer to NULL. 4. The descendant loads NULL and dereferences rka->cred. This NULL dereference can oops the kernel. RCU delays payload disposal but does not prevent the pointer from being cleared. Load the payload with dereference_key_rcu() and require a non-NULL result before validating the authorization key and searching its saved credentials. A non-NULL payload and its credentials remain alive for the caller's RCU read-side section; a cleared payload skips the fallback search and follows the existing error selection. KASAN report as below: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000005: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f] RIP: 0010:search_process_keyrings_rcu+0x32b/0x790

What to do

  • Workaround: The checked facts give no workaround or mitigation. Consult the kernel vendor's advisory for guidance while a fix is pending.

Timeline

  1. CVE published
  2. First seen by cve.now

Affected versions

  • Linux Linux

    Version range not reported

  • Linux Linux

    5.3

Evidence 8

  1. Link
  2. Link
  3. Link
  4. Link
  5. Link
Show all 8 sourcesShow fewer sources
  1. Link
  2. Link
  3. Link

Corrections

None so far.

Something wrong on this page? Report an error. Every fix is listed here.

FAQ

Questions about CVE-2026-99225

What does this mean?

A request-key helper can assume authority and fork a child process that inherits the authorization key. If the child misses in its own keyrings, it falls back to the saved requestor credentials, and a NULL pointer dereference can oops (crash) the kernel.Source: git.kernel.org

Am I affected, and how do I check?

The checked facts list only the Linux kernel and give no version ranges. The setup involves request-key helpers that fork descendants inheriting the authorization key, so check the kernel version with uname -r and compare it against the kernel vendor's advisory.Source: git.kernel.org

What should I do about it?

The checked facts name no fixed version or patch, so the upgrade target cannot be stated from these facts. Check the kernel vendor's advisory or your distribution's security notices for a fixed kernel.Source: git.kernel.org

Is it being exploited?

It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked.Source: cve.now feed data

What if there's no patch?

The checked facts give no workaround or mitigation. Consult the kernel vendor's advisory for guidance while a fix is pending.Source: git.kernel.org