The CVE describes a missing case handler in nfsd4_drop_revoked_stid() for layout stateids, and the fix is straightforward — add SC_TYPE_LAYOUT to unhash the stid and drop its creation reference. But framing this as a simple cleanup oversight misses the actual threat model. A compromised or malicious pNFS client can trigger repeated layout delegation and revocation, then issue FREE_STATEID against revoked layouts. Because the revocation path lacks the case handler, each such operation leaves a zombie stid in both the IDR namespace and the per-client list. The stid holds references into the layout subsystem and per-file structures. These accumulate unbounded until the client connection drops. That's a resource-exhaustion DoS vector, not a bookkeeping bug.
What makes this exploitable is the reference graph behind the stid. The per-file layout list is also traversed by the fence worker — the mechanism that forcibly recalls layouts from non-compliant clients. If zombie stids accumulate on that list, fence operations on active pNFS I/O face a lengthened critical path under a lock. The IDR is a system-wide namespace; unbounded growth under one client degrades stateid lookup performance for all clients on the server.
The deeper concern is structural. The happy path for layout stateids (delegation, recall, normal FREE_STATEID) has complete coverage. The revocation path — the exact scenario this CVE exposes — appears to have never been exercised in integration testing. The missing case handler isn't a logic error; it's evidence that the revocation workflow was never treated as a first-class test scenario. This raises a practical question: how many other SC_TYPE cases in nfsd4_drop_revoked_stid() have similar gaps, and has the reference graph from stid types to shared kernel objects been audited for other accumulation points beyond the revocation path?
If you're defending a system running pNFS servers, the patch is necessary but insufficient. Monitor for growth in the nfsd4_stid IDR under sustained pNFS client activity. Check whether your NFSD test suite includes a scenario where an admin revokes a layout and the client issues FREE_STATEID. If it doesn't, that's the same coverage gap that allowed this to ship.