CVE-2026-89681: nfsd: fix layout fence worker double-reference race
In the Linux kernel, the following vulnerability has been resolved:
nfsd: fix layout fence worker double-reference race
The workqueue core clears WORKSTRUCTPENDING before the callback is invoked, so delayedworkpending() in lmbreakertimedout() can return false while the fence worker is already running. This lets the breaker take a duplicate sccount reference and schedule a new worker that coalesces with the in-progress one. The extra reference is never put, leaking the layout stateid.
Replace the racy delayedworkpending() check with an lsfenceinflight boolean set atomically with refcountincnotzero() under lslock, and cleared under lslock before the final nfs4putstid() on the dispose path; the retry path intentionally retains it. Remove the self-rearm moddelayedwork() at the top of the worker.
Affected Software
Event History
Frequently Asked Questions
What systems are exposed to this issue?
Systems running the Linux kernel NFS server component (nfsd) are relevant. The issue involves layout fence worker handling and can leak an NFS layout stateid when the described worker race occurs.
What conditions trigger the leak?
The race occurs when the workqueue has cleared WORK_STRUCT_PENDING before the fence worker callback begins. In that window, lm_breaker_timedout() can see delayed_work_pending() as false, take a duplicate sc_count reference, and schedule work that coalesces with the worker already in progress.
Is there a documented workaround if the fix cannot be applied immediately?
No workaround or configuration mitigation is provided in the available data. The referenced resolution replaces the racy pending-work check with ls_fence_inflight synchronization under ls_lock and removes the worker's self-rearm operation.