CVE-2025-68299: afs: Fix delayed allocation of a cell's anonymous key
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.
Security readout for executives and security teams
Plain-English summary
A timing flaw in the Linux kernel's AFS filesystem can cause a kernel crash while an AFS cell is being prepared and its authentication key is requested. The resulting system disruption could affect availability. The supplied sources do not establish severity, affected-version ranges, or remote exploitability.
Executive priority
Treat this as a targeted availability risk requiring prompt inventory, not an assumed enterprise-wide emergency. Escalate patching where AFS is operationally important or kernel crashes carry high business impact. Broader urgency cannot be justified until vendors publish affected-version and severity guidance.
Technical view
A race can leave an AFS cell's anonymous key description unset when normal key lookup passes it to request_key(), causing a kernel oops. The fix creates a stable reference name with the cell, allocates the anonymous key on demand under a mutex, and safely exits RCU mode when allocation is pending.
Likely exposure
Potential exposure is limited to Linux systems using the AFS filesystem and reaching the described cell lookup and key-request path. The bundle lists Linux 6.17.9 and three commit identifiers as unaffected, but provides no complete vulnerable-version range. Systems not using AFS are unlikely to reach this code path.
Exploitation context
The supplied record does not identify active exploitation, public exploit code, or inclusion in CISA KEV. Triggering is associated with parsing an AFS mount device name and a timing-dependent key lookup. Required privileges, attacker access, reliability, and remote reachability are not established by the provided evidence.
Researcher notes
The failure is a race between asynchronous AFS cell setup and authentication-key lookup. The remediation changes object initialization, serializes lazy anonymous-key allocation, and handles the missing-key case during RCU lookup. The supplied affected data is insufficient to reconstruct introduction and fixed-version boundaries; consult Linux distribution advisories before declaring exposure.
Mitigation direction
Identify Linux systems with AFS enabled or actively mounted.
Check distribution advisories for kernels incorporating the cited upstream fixes.
Prioritize kernel updates on availability-sensitive systems using AFS.
Where operationally acceptable, avoid AFS use until affected-version status is confirmed.
Validation and detection
Record running kernel versions and compare them with vendor advisories.
Confirm whether AFS modules, mounts, or related services are present.
Verify the installed kernel includes the applicable cited fix.
Review kernel logs for AFS-related oopses or key-request failures.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2025-68299 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
0CVSS vectors
3Timeline events
0ADP providers
4Source links
Vulnerability timeline
Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.
CVE reservedCVE Program
The CVE ID was reserved by the assigning CNA.
CVE publishedCVE Program
The CVE record was published.
Dec 16, 2025, 15:06 UTC (UTC+00:00)
CVE updatedCVE Program
The CVE record metadata indicates this as the latest update time.