GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration

GHSA-F2VV-WRGM-2RRJ

Vulnerability from github – Published: 2026-09-11 21:31 – Updated: 2026-09-13 09:32
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

nfsd: close shrinker/GC/fsnotify vs per-net shutdown race in filecache

The shrinker, GC worker, and fsnotify/lease callbacks can unhash an nfsd_file from the rhashtable and then call nfsd_file_dispose_list_delayed() to move it to the per-net dispose list. If nfsd_file_cache_shutdown_net() runs concurrently, its rhashtable walk misses the already-unhashed file, and its drain of the per-net dispose list can run before the file has been queued. The file then sits on the per-net list with no thread to drain it, leaking both the file and its associated state.

The GC worker and shrinker already hold nfsd_gc_lock while walking the LRU, but in the original code they release it before calling nfsd_file_dispose_list_delayed(). The fsnotify/lease path (nfsd_file_close_inode) has no synchronization at all.

Fix this by:

  1. Widening nfsd_gc_lock in both nfsd_file_gc() and nfsd_file_lru_scan() to cover the nfsd_file_dispose_list_delayed() call.

  2. Wrapping nfsd_file_close_inode() in nfsd_gc_lock so that all three callers of nfsd_file_dispose_list_delayed() hold the lock.

  3. Adding a spin_lock/unlock(nfsd_gc_lock) barrier in nfsd_file_cache_shutdown_net() after the purge, so that any in-progress disposal has fully completed before the per-net list is drained.

All operations inside the lock are non-sleeping (rhashtable lookups, atomic bit/refcount ops, list moves, svc_wake_up), so the spinlock is appropriate.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-89667"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-11T20:19:53Z",
    "severity": "HIGH"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: close shrinker/GC/fsnotify vs per-net shutdown race in filecache\n\nThe shrinker, GC worker, and fsnotify/lease callbacks can unhash an\nnfsd_file from the rhashtable and then call\nnfsd_file_dispose_list_delayed() to move it to the per-net dispose list.\nIf nfsd_file_cache_shutdown_net() runs concurrently, its rhashtable walk\nmisses the already-unhashed file, and its drain of the per-net dispose\nlist can run before the file has been queued.  The file then sits on\nthe per-net list with no thread to drain it, leaking both the file and\nits associated state.\n\nThe GC worker and shrinker already hold nfsd_gc_lock while walking the\nLRU, but in the original code they release it before calling\nnfsd_file_dispose_list_delayed().  The fsnotify/lease path\n(nfsd_file_close_inode) has no synchronization at all.\n\nFix this by:\n\n  1. Widening nfsd_gc_lock in both nfsd_file_gc() and nfsd_file_lru_scan()\n     to cover the nfsd_file_dispose_list_delayed() call.\n\n  2. Wrapping nfsd_file_close_inode() in nfsd_gc_lock so that all three\n     callers of nfsd_file_dispose_list_delayed() hold the lock.\n\n  3. Adding a spin_lock/unlock(nfsd_gc_lock) barrier in\n     nfsd_file_cache_shutdown_net() after the purge, so that any\n     in-progress disposal has fully completed before the per-net list\n     is drained.\n\nAll operations inside the lock are non-sleeping (rhashtable lookups,\natomic bit/refcount ops, list moves, svc_wake_up), so the spinlock is\nappropriate.",
  "id": "GHSA-f2vv-wrgm-2rrj",
  "modified": "2026-09-13T09:32:27Z",
  "published": "2026-09-11T21:31:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89667"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/08af9593e2b472fd98c00faf1bf03bdbb7203477"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/40162cfea79b9510380decfdd1795b754dc9f972"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/6d6b9f6a75c3767250e9c23ace4e384ab8f7843e"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.


Loading…