From: AL-KERNEL <[email protected]>
To: [email protected]
Subject: [CVE-2026-89708][IMPORTANT] nfsd: RCU-protect cl_cb_session to fix use-after-free on session teardown
Date: Sat, 12 Sep 2026 02:13:49 -0400 [thread overview]
Message-ID: <[email protected]> (raw)
CVE: CVE-2026-89708
Priority: IMPORTANT
AL-KERNEL base severity: IMPORTANT
KPANIC flag: YES
Patch: nfsd: RCU-protect cl_cb_session to fix use-after-free on session teardown
Commit: f164eb52b6f3cbf40f07fe379f9f421f88e02f76
Upstream patch: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=f164eb52b6f3cbf40f07fe379f9f421f88e02f76
Original CVE announcement: https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-89708
Analysis date: Sat, 12 Sep 2026 02:13:49 -0400
ActionableScore: 7
ActionableScore lower bound: 5
Actionable bucket: Strong Important candidate
Manual review required: YES
Summary:
A remote NFSv4.1 client can trigger a session teardown race where nfsd callback tasks on rpciod dereference a freed cl_cb_session, causing at least kernel crash DoS and requiring manual review for possible UAF memory corruption impact.
======================================================================
ABOUT THIS REPORT
======================================================================
The original Linux kernel CVE announcement for CVE-2026-89708 is available here:
https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-89708
The original announcement does not normally provide a security severity
estimate, CVSS assessment, or enough information to determine whether the
reported kernel bug represents a practically relevant security issue.
This report was generated by AL-KERNEL, an AI-assisted Linux kernel
vulnerability analysis system developed by Alexander Larkin. It combines
an autonomous classifier with LLM-assisted technical analysis and a
separate ActionableScore mechanism.
The purpose of this report is to prioritize Linux kernel CVEs before
manual review, identify cases that require prompt investigation, and
support automatic closure of issues that are unlikely to have meaningful
security impact.
Published priority for this report: IMPORTANT
Manual review required: YES
A detailed explanation of the methodology and priority rules is included
at the end of this message.
======================================================================
AL-KERNEL CLASSIFICATION RESULT
======================================================================
CVE-2026-89708 IMPORTANT https://www.kernelcve.org/list/?q=CVE-2026-89708 CHECK WITH IMPACT FROM ORIG NN MODERATE Maybe valid. Check manually. Hints by AL-KERNEL: The best (paranoid) CVSS is 'AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H';*CWE-416;CWE-362;*CWE-672;Other CVSS 'AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:H';BEST CVSS score: '8.1';DESCR 'An NFSv4.1 server use-after-free can occur when DESTROY_SESSION tears down and frees a session while an asynchronous callback rpc_task is still running later on rpciod. The stale cl_cb_session pointer can then be dereferenced from callback encoding, decoding, slot handling, or completion paths after the session slab has been released. For the CVSS the PR:N is used because a remote NFS client can reach the vulnerable nfsd session and callback paths over the exposed NFS service without local code execution on the target. AC:H is used because reliable triggering depends on a race between session teardown and delayed callback task execution. Impact is at least remote denial of service via kernel crash and in the paranoid case may include confidentiality or integrity impact due to use-after-free memory corruption. NFS servers are commonly exposed only on trusted internal storage or data center networks, but any reachable NFSv4.1 service with callback support should be treated as needing manual review.';YES REQUIRES MANUAL CHECK; ,and ActionableScore result is Strong Important candidate (with actual score 6) YES READ LOCK DISK INIT RACE UAF NETWORK KPANIC KPANIC INCREASED_TO_HIGH_BASED_ON_GUESSCVSS NO NO checked
======================================================================
ACTIONABLESCORE ANALYSIS
======================================================================
ActionableScore=7
ActionableScoreLower=5
PrimitiveClass=CLASS_B
RealUAF=YES
HostAdminRequired=NO
NamespaceScopedPrivilege=NO
ImportantCandidate=YES
ManualReview=REQUIRED
AutoDowngradeAllowed=NO
## 1. ActionableScore
* Raw conservative score: 5
* Conservative score: 5
* Raw paranoid score: 7
* Paranoid score: 7
* Final recommended bucket: **Strong Important candidate**::
No floor or cap changed the score.
## 2. Signal breakdown
Conservative signals:
* +2 Remote reachable / directly network-triggerable: a remote NFSv4.1 client can reach the nfsd session and callback paths over the exposed NFS service.
* +2 Real UAF / active lifetime violation: `cl_cb_session` can point to a freed `struct nfsd4_session` while an asynchronous `rpc_task` on `rpciod` still dereferences it.
* +1 Concrete RCU referenced-object lifetime mismatch: the fix converts `cl_cb_session` to an RCU pointer and changes `kfree()` to `kfree_rcu()`, showing that legitimate concurrent readers needed the session lifetime extended past teardown.
* +1 Reliable kernel crash / strong DoS: the stale session pointer is dereferenced in callback encode/decode, slot handling, and completion paths, supporting kernel crash / DoS.
* -1 Hard or timing-sensitive race: reliable triggering depends on the ordering between `DESTROY_SESSION`, session teardown, callback workqueue flushing, delayed `rpciod` tasks, and callback retry timing.
Paranoid additional signals:
* +1 Structured stale-object exploitation leverage: the stale object is an active structured NFS session, and later paths read and modify meaningful fields such as session IDs, callback sequence state, slot state, and lock-protected slot availability. This is more than a single immediate NULL dereference, although controlled reclaim is not demonstrated.
* The paranoid score does not apply the race penalty because the commit describes delayed `rpciod` tasks and NFS4ERR_DELAY retries that can make the stale-use window practically reachable under repeated protocol activity.
Important non-awarded signals:
* Controlled reclaim is not demonstrated.
* Arbitrary or directed kernel write is not demonstrated.
* CLASS_A is not assigned because there is no proven controlled replacement, function-pointer control, arbitrary R/W, or demonstrated LPE.
* Extra Availability was not awarded because the crash / DoS is already counted once.
* Confidentiality and Integrity are not scored as direct established consequences in ActionableScore, although paranoid CVSS may reasonably use higher C/I for manual triage because this is a network-reachable UAF.
* Concrete repeated release/refcount mutation is not awarded. The stale paths dereference and modify session fields, but the supplied patch does not show a second lifetime/refcount decrement on the exact same dangling session reference.
Repeated-release/refcount check:
* First release can end lifetime: yes, session teardown reaches `free_session()` / `__free_session()` and previously used `kfree(ses)`.
* Exact same reference survives: yes, `clp->cl_cb_session` can retain the stale pointer.
* Second operation is a real lifetime/refcount mutation: no concrete second put/free/refcount operation on the exact same stale session is shown.
* +1 Concrete repeated release/refcount awarded: no.
* Paranoid repeated-refcount leverage awarded: no.
* FLOOR 5 applied: no explicit floor applied, raw conservative score already reaches 5.
## 3. Reachability analysis
The evaluated attacker is a remote NFS client, not a local host user. The vulnerable sequence is in the NFSv4.1 server callback and session teardown machinery. A client that can establish and destroy an NFSv4.1 session and influence callback timing can reach the relevant paths over the NFS service.
Host administrator privilege is not required by the supplied evidence for the attacker role, so `HostAdminRequired=NO`. This is not a namespace-scoped local capability issue, so `NamespaceScopedPrivilege=NO`.
There is likely prior operational setup because the system must be running nfsd with NFSv4.1 callback support and the NFS service must be reachable. That is normal deployment setup, not an attacker privilege requirement for the vulnerable operation.
The race is timing-sensitive. It requires overlap between session teardown and an inflight callback `rpc_task` that has moved from `cl_callback_wq` to `rpciod`, possibly delayed by retry behavior such as `NFS4ERR_DELAY`. The commit gives a concrete lifetime window rather than a purely theoretical race.
No special hardware is required.
## 4. Primitive and severity interpretation
The exact primitive is a stale post-lifetime use of `clp->cl_cb_session`, where an NFSv4.1 session can be freed during `DESTROY_SESSION` while `rpciod` callback tasks still read or modify the session through the stale pointer.
This is an active structured object UAF, not fixed stale storage. The stale object is `struct nfsd4_session`, and the stale paths include callback argument encoding, callback result decoding, callback slot acquisition/release, callback preparation, callback completion, and tracepoint paths.
This is broader than a shallow cleanup-only stale dereference. The stale session participates in active protocol state handling and slot management. However, the patch does not establish controlled reclaim, attacker-shaped replacement contents, arbitrary kernel read/write, function-pointer dispatch, credential overwrite, or a demonstrated privilege escalation chain.
Primitive class is `CLASS_B`: a real active-object UAF with unresolved exploitation leverage, but without a directly established strong corruption primitive.
Demonstrated consequence is remote kernel crash / denial of service. Speculative consequence is stronger memory corruption impact if freed session memory is reused and stale callback processing acts on reclaimed storage, but that stronger path is not proven by the patch.
`ImportantCandidate=YES` because this is a network-reachable active structured UAF in kernel server code, with RCU lifetime repair and nontrivial stale object processing. `AutoDowngradeAllowed=NO` because automatic Moderate closure would discard a meaningful unresolved kernel lifetime-corruption primitive.
Operationally, this should be treated as at least Actionable Moderate and a strong Important candidate for manual security review.
## 5. One-sentence report phrase
A remote NFSv4.1 client can trigger a session teardown race where nfsd callback tasks on rpciod dereference a freed cl_cb_session, causing at least kernel crash DoS and requiring manual review for possible UAF memory corruption impact.
## 6. Manual review recommendation
MANUAL CHECK REQUIRED
Reason: this is a remote, kernel-server-side, active structured UAF fixed with RCU lifetime protection and `kfree_rcu()`. The confirmed impact is DoS, but the stale object is used in nontrivial callback and slot-management paths, so Important-vs-Moderate exploitation leverage remains unresolved.
## 7. Call-site confidence
Call-site confidence: high
======================================================================
UPSTREAM PATCH SUMMARY
======================================================================
Patch: nfsd: RCU-protect cl_cb_session to fix use-after-free on session teardown
Commit: f164eb52b6f3cbf40f07fe379f9f421f88e02f76
Upstream URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=f164eb52b6f3cbf40f07fe379f9f421f88e02f76
Commit description:
After a DESTROY_SESSION the per-session teardown path can free a
session while rpciod still holds an inflight callback rpc_task that
dereferences clp->cl_cb_session. nfsd4_probe_callback_sync() flushes
cl_callback_wq, but once nfsd4_run_cb_work() has called
rpc_call_async() the rpc_task lives on rpciod; flushing the workqueue
does not wait for it. rpc_shutdown_client() does drain rpciod tasks,
but uses a 1-second wait_event_timeout — tasks stuck in rpc_delay()
(e.g. 2-second NFS4ERR_DELAY retries) can outlive the drain.
destroy path rpciod
------------ ------
unhash_session(ses)
nfsd4_probe_callback_sync(clp)
flush_workqueue(cl_callback_wq)
/* returns; rpc_task still live */
nfsd4_put_session_locked(ses)
free_session(ses) -> kfree(ses)
nfsd4_cb_sequence_done()
reads cb_clp->cl_cb_session
/* freed slab */
A second window exists in nfsd4_process_cb_update(). When
__nfsd4_find_backchannel() returns NULL because unhash_session() has
already removed the destroyed session from cl_sessions,
setup_callback_client() takes the v4.1 early return so
clp->cl_cb_session = ses never fires and the field retains a pointer
to the about-to-be-freed session.
Fix both by converting cl_cb_session to an RCU-protected pointer:
- Move the cl_cb_session = ses assignment in setup_callback_client()
to after rpc_create() succeeds, so it is only published when a
working backchannel exists. Clear cl_cb_session on the error
return in nfsd4_process_cb_update(). Both stores use
rcu_assign_pointer().
- Annotate cl_cb_session with __rcu. All rpciod-side readers use
rcu_read_lock()/rcu_dereference() and check for NULL, bailing to
the appropriate error or requeue path:
encode_cb_sequence4args(), decode_cb_sequence4resok(),
nfsd41_cb_get_slot(), nfsd41_cb_release_slot(),
nfsd4_cb_prepare(), and nfsd4_cb_sequence_done().
- Switch __free_session() from kfree() to kfree_rcu() so the
session slab is not reclaimed until after an RCU grace period,
guaranteeing that rpciod readers inside rcu_read_lock() never
dereference freed memory.
- Pass the session pointer to the nfsd_cb_seq_status and
nfsd_cb_free_slot tracepoints instead of having them re-read
cl_cb_session.
- nfsd4_cb_prepare() calls rpc_exit() when the session is NULL,
routing through the done/release path to requeue the callback.
Fixes: dcbeaa6 ("nfsd4: allow backchannel recovery")
Cc: [email protected]
Reported-by: Chris Mason <[email protected]>
Signed-off-by: Chris Mason <[email protected]>
Signed-off-by: Jeff Layton <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Chuck Lever <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Changed files:
fs/nfsd/nfs4callback.c
fs/nfsd/nfs4state.c
fs/nfsd/state.h
fs/nfsd/trace.h
Diff excerpt:
Not included in this email. See the upstream URL for the full patch.
Full patch:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=f164eb52b6f3cbf40f07fe379f9f421f88e02f76
======================================================================
DETAILED REPORT METHODOLOGY
======================================================================
The original Linux kernel CVE announcement for CVE-2026-89708 can be found here:
https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-89708
The original CVE announcement normally does not include a security-level
estimate. In particular, it may not contain a CVSS assessment, an impact
level, or enough information to determine whether the reported bug is a
practically relevant security issue. One purpose of this parallel CVE list
is to provide that missing technical and prioritization information.
The original goal of the AL-KERNEL project was to prioritize Linux kernel
CVE analysis automatically before manual review. The system can also help
identify non-security issues that may be suitable for automatic closure.
This report was generated by AL-KERNEL, an AI-assisted Linux kernel
vulnerability analysis system developed by Alexander Larkin.
The first analysis stage combines an autonomous classifier with additional
LLM-based analysis. The autonomous classifier runs locally on a CPU and is
based on a backpropagation neural network. Together, these mechanisms
produce a technical vulnerability description, identify likely weakness
types, estimate CVSS severity, and provide input for ActionableScore.
Two CVSS estimates are retained because incomplete kernel vulnerability
information often permits more than one defensible interpretation:
Conservative CVSS vector: AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:H
The Best / paranoid CVSS vector: AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
The Best / paranoid CVSS score: 8.1
The conservative vector represents a lower-impact interpretation.
The Best/paranoid vector intentionally represents a plausible upper-bound
interpretation and should not automatically be treated as demonstrated
real-world impact.
CVSS may also need to be adjusted for a particular Linux deployment,
because actual reachability, privileges, enabled kernel configuration,
hardware, namespaces, exposed device nodes, and other environmental
conditions can differ significantly between systems.
A separate ActionableScore mechanism evaluates practical remediation
urgency. Its analysis may include reachability, attack prerequisites,
subsystem exposure, memory-corruption characteristics, denial-of-service
reliability, and possible confidentiality, integrity, or
privilege-escalation impact.
Conservative ActionableScore: 5
Paranoid ActionableScore: 7
The final base severity is taken directly from the second tab-separated
field of the AL-KERNEL classification result. ActionableScore does not
replace or independently override that final AL-KERNEL decision, and
if ActionableScore adjusted impact level of ALKERNEL, then you would see
self-readable flags above like INCREASED_TO_HIGH_BASED_ON_ACTIONABLESCOREHIGHEREQTHAN7.
For an AL-KERNEL result of MODERATE, this report uses the following
additional presentation split:
ActionableScore below 5 -> MODERATE REGULAR
ActionableScore 5 or more -> MODERATE 7.0
The distinction between MODERATE REGULAR and MODERATE 7.0 makes it
possible to identify Moderate issues that should receive manual analysis
and fixes before lower-priority MODERATE REGULAR issues. In many cases,
MODERATE REGULAR fixes may wait for a later rebase or routine update.
There is one override in which MODERATE REGULAR becomes MODERATE 7.0
even when the ActionableScore is below 5. When the AL-KERNEL result
contains the KPANIC flag, a MODERATE result is always presented as
MODERATE 7.0. The KPANIC flag selected with few regexps without
usage of AI at all, so it helps to detect cases when Kernel Crash happens
and similar (to filter False-Negative results from the LLM usage).
KPANIC indicates that a reliable kernel crash, kernel panic, or similarly
serious kernel availability impact was identified by the classification
workflow.
AL-KERNEL base severity for this report: IMPORTANT
KPANIC detected for this report: YES
Published priority for this report (same as in Subject): IMPORTANT
These results are intended to support engineering triage. They are
machine-generated estimates, and cases marked for manual review should
be validated by a human security engineer before final disposition.
For more info read docs linked from here: https://kernelcve.org/
(and you can submit you own patch there to generate such a report
for non-existant CVE-id yet).
Note that in many cases this AI tool selects higher severity, than
real is (means you can expect Importants instead of Moderate 7.0 or
Moderates 7.0 instead of regular Moderates). If you see such cases,
please use reply email interface to add additional manual analyses
info to this particular CVE.
And please, please, let me know when you see Lows instead of Importants
or Important instead of Low (because particular for such cases I
need to tune this AI tool to make it better for this one and next similar).
My contact email for such notifications is [email protected] (and both
send reply to CVE record itself too and see "reply" button below for howto reply).
reply other threads:[~2026-09-12 6:13 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --from, and --in-reply-to
switches of git-send-email(1) and next cmd tested by kernelcve.org admin:
git send-email --smtp-server=mail.kernelcve.org --smtp-server-port=25 --smtp-auth=none --from='Your Name <youremail@domain.is>' --suppress-cc=all --no-cc \
--in-reply-to=cve-2026-89708.1ee93cf52b881d9757ee4946@kernelcve.org \
[email protected] \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
The file with msg could look like this then:
cat YOUR_REPLY
Subject: Re: [CVE-2026-64206][MODERATE REGULAR] Bluetooth: L2CAP test
Just testing public-inbox replies.
Thanks,
MyName
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox