{"answers":{"affected":"","exploited":"There is no known exploitation of CVE-2026-89714 in the wild and no public exploit code.","fix":"Apply the vendor's patch.","what":"CVE-2026-89714 is a memory corruption vulnerability in Linux, published on 11 Sep 2026. It can only be exploited from the same machine or local network, with no action from the victim."},"fix_prompt":"Check this codebase for CVE-2026-89714 and fix it if it is affected.\n\nWhat it is: CVE-2026-89714 is a memory corruption vulnerability in Linux, published on 11 Sep 2026. It can only be exploited from the same machine or local network, with no action from the victim.\nExploitation: There is no known exploitation of CVE-2026-89714 in the wild and no public exploit code.\n\nAffected product: Linux. No package-level version data is available, so check the vendor advisory linked from the reference page.\n\nTask:\n1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.\n2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.\n3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.\n4. Run the tests and summarise what changed and why.\n5. If nothing in the project is affected, say so and change nothing.\n\nReference: https://insights.sbomify.com/CVE-2026-89714/ (Markdown: https://insights.sbomify.com/CVE-2026-89714/index.md)","id":"CVE-2026-89714","markdown":"https://insights.sbomify.com/CVE-2026-89714/index.md","name":"CVE-2026-89714","record":{"aliases":["BELL-CVE-2026-89714","DEBIAN-CVE-2026-89714","GHSA-hv3g-87gw-4m9v","UBUNTU-CVE-2026-89714"],"analysis":{"component_type":"kernel","fix_type":"patch","impacts":["denial_of_service"],"network_reachable":"adjacent_or_local","non_default_config":false,"product_category":"Linux kernel NFS","requires_auth":"low_privilege","summary":"A memory leak in the Linux kernel NFS client allows local attackers to exhaust kernel memory by repeatedly failing NFSv4 mounts, causing denial of service.","user_interaction":"not_required","vuln_class":"memory_corruption"},"analysis_generated_by":"qwen3.8-flash-next","assigner":"Linux","cpe":[],"cvss":{"score":null,"severity":null,"source":null,"vector":null,"version":null},"cwes":[],"description":"In the Linux kernel, the following vulnerability has been resolved:\n\nNFS: fix delegation_hash_table leak when nfs4_server_common_setup() fails\n\nnfs4_server_common_setup() allocates server-\u003edelegation_hash_table\nfirst, but server-\u003edestroy - the only path that frees the table via\nnfs4_destroy_server() - is not assigned until the very end of the\nfunction. If any intermediate step fails (the is_ds_only_client()\ncheck, nfs4_init_session(), nfs4_get_rootfh(), or nfs_probe_server()),\nthe function returns with server-\u003edestroy still NULL, so the caller's\nnfs_free_server() skips the destroy callback and the hash table is\nleaked (4 KiB per attempt with the default delegation watermark).\n\nThis is trivially reachable from userspace: every failed NFSv4 mount\nleaks one allocation. A client that persistently retries a mount that\ncannot succeed leaks kernel memory without bound. Observed in\nproduction where a Longhorn backup poller retried mount.nfs4 against\nan NFSv3-only server roughly 10 times per second, leaking ~3.4 GiB of\nunreclaimable slab (kmalloc-rnd-13-4k) per day; the node accumulated\n12 GiB of leaked slab before the source was identified via the\nkmem:kmalloc tracepoint (call_site=nfs4_delegation_hash_alloc).\n\nReproducer:\n\n  # server exports NFSv3 only (or export path absent for v4)\n  while :; do mount -t nfs4 \u003cserver\u003e:/missing /mnt; done\n  # watch SUnreclaim in /proc/meminfo grow 4 KiB per iteration\n\nFree the table on the error paths between the allocation and the\nassignment of server-\u003edestroy.","ecosystems":[],"exploits":{"exploitdb":0,"first_seen":null,"github_poc":0,"max_poc_stars":null,"metasploit":0,"nuclei":0,"refs":[],"tier":"none_known"},"has_fix":true,"headline":"NFS: fix delegation_hash_table leak when nfs4_server_common_setup() fails","id":"CVE-2026-89714","indexable":true,"kev":null,"kind":"cve","links":{"ecosystem":null,"product":null,"products":[],"type":"memory_corruption","year":"2026"},"n_packages":0,"n_references":3,"next":{"headline":"NFS/localio: fix ref leak on nfs_uuid_add_file failure","id":"CVE-2026-89715"},"packages":[],"prev":{"headline":"NFSD: check truncate permission under inode lock","id":"CVE-2026-89713"},"products":["Linux"],"published":"2026-09-11","related":[],"sources":[{"class":"attribution","licence":"CVE Terms of Use (MITRE)","name":"CVE List","prefix":"CVE"}],"ssvc":{"automatable":null,"exploitation":null,"technical_impact":null},"state":"PUBLISHED","updated":"2026-10-19","vendors":["Linux"]},"summary":"A memory leak in the Linux kernel NFS client allows local attackers to exhaust kernel memory by repeatedly failing NFSv4 mounts, causing denial of service.","url":"https://insights.sbomify.com/CVE-2026-89714/"}