CVE-2025-68299
Description
In the Linux kernel, the following vulnerability has been resolved:
afs: Fix delayed allocation of a cell's anonymous key
The allocation of a cell's anonymous key is done in a background thread along with other cell setup such as doing a DNS upcall. In the reported bug, this is triggered by afs_parse_source() parsing the device name given to mount() and calling afs_lookup_cell() with the name of the cell.
The normal key lookup then tries to use the key description on the anonymous authentication key as the reference for request_key() - but it may not yet be set and so an oops can happen.
This has been made more likely to happen by the fix for dynamic lookup failure.
Fix this by firstly allocating a reference name and attaching it to the afs_cell record when the record is created. It can share the memory allocation with the cell name (unfortunately it can't just overlap the cell name by prepending it with "afs@" as the cell name already has a '.' prepended for other purposes). This reference name is then passed to request_key().
Secondly, the anon key is now allocated on demand at the point a key is requested in afs_request_key() if it is not already allocated. A mutex is used to prevent multiple allocation for a cell.
Thirdly, make afs_request_key_rcu() return NULL if the anonymous key isn't yet allocated (if we need it) and then the caller can return -ECHILD to drop out of RCU-mode and afs_request_key() can be called.
Note that the anonymous key is kind of necessary to make the key lookup cache work as that doesn't currently cache a negative lookup, but it's probably worth some investigation to see if NULL can be used instead.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
A use-before-set of the anonymous authentication key in the Linux kernel's AFS filesystem can cause an oops during mount.
Vulnerability
In the Linux kernel's AFS (Andrew File System) client, the anonymous authentication key for a cell is allocated in a background thread during cell setup. However, a mount operation may trigger a key lookup before this allocation completes, leading to a NULL pointer dereference and system crash. The issue was exacerbated by a prior fix for dynamic lookup failure.
Attack
Vector An attacker who can trigger an AFS mount (e.g., via a crafted device name in mount()) can cause the kernel to attempt to use the cell's anonymous key before it is initialized. This requires the ability to mount an AFS filesystem, which typically needs local access or the ability to configure mounts. No authentication is needed for the initial mount attempt.
Impact
Successful exploitation results in a kernel oops, leading to a denial of service (DoS) by crashing the system. There is no indication of privilege escalation or data corruption.
Mitigation
The fix, committed in kernel version 5.10-stable and later, allocates the key's reference name at cell creation and allocates the anonymous key on demand with a mutex. Users should update their Linux kernel to include commit 5613bde937df. No workaround is available; the issue is fixed in stable kernels [1].
AI Insight generated on May 19, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.
Affected products
2Patches
0No patches discovered yet.
Vulnerability mechanics
AI mechanics synthesis has not run for this CVE yet.
References
2News mentions
0No linked articles in our index yet.