https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Wed, 30 Sep 2026 01:59:37 +0000 https://vulnerability.circl.lu/vuln/cve-2026-89714 <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>NFS: fix delegation_hash_table leak when nfs4_server_common_setup() fails</p> <p>nfs4_server_common_setup() allocates server-&gt;delegation_hash_table first, but server-&gt;destroy - the only path that frees the table via nfs4_destroy_server() - is not assigned until the very end of the function. If any intermediate step fails (the is_ds_only_client() check, nfs4_init_session(), nfs4_get_rootfh(), or nfs_probe_server()), the function returns with server-&gt;destroy still NULL, so the caller&#39;s nfs_free_server() skips the destroy callback and the hash table is leaked (4 KiB per attempt with the default delegation watermark).</p> <p>This is trivially reachable from userspace: every failed NFSv4 mount leaks one allocation. A client that persistently retries a mount that cannot succeed leaks kernel memory without bound. Observed in production where a Longhorn backup poller retried mount.nfs4 against an NFSv3-only server roughly 10 times per second, leaking ~3.4 GiB of unreclaimable slab (kmalloc-rnd-13-4k) per day; the node accumulated 12 GiB of leaked slab before the source was identified via the kmem:kmalloc tracepoint (call_site=nfs4_delegation_hash_alloc).</p> <p>Reproducer:</p> <p># server exports NFSv3 only (or export path absent for v4) while :; do mount -t nfs4 &lt;server&gt;:/missing /mnt; done # watch SUnreclaim in /proc/meminfo grow 4 KiB per iteration</p> <p>Free the table on the error paths between the allocation and the assignment of se…</p> <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>NFS: fix delegation_hash_table leak when nfs4_server_common_setup() fails</p> <p>nfs4_server_common_setup() allocates server-&gt;delegation_hash_table first, but server-&gt;destroy - the only path that frees the table via nfs4_destroy_server() - is not assigned until the very end of the function. If any intermediate step fails (the is_ds_only_client() check, nfs4_init_session(), nfs4_get_rootfh(), or nfs_probe_server()), the function returns with server-&gt;destroy still NULL, so the caller&#39;s nfs_free_server() skips the destroy callback and the hash table is leaked (4 KiB per attempt with the default delegation watermark).</p> <p>This is trivially reachable from userspace: every failed NFSv4 mount leaks one allocation. A client that persistently retries a mount that cannot succeed leaks kernel memory without bound. Observed in production where a Longhorn backup poller retried mount.nfs4 against an NFSv3-only server roughly 10 times per second, leaking ~3.4 GiB of unreclaimable slab (kmalloc-rnd-13-4k) per day; the node accumulated 12 GiB of leaked slab before the source was identified via the kmem:kmalloc tracepoint (call_site=nfs4_delegation_hash_alloc).</p> <p>Reproducer:</p> <p># server exports NFSv3 only (or export path absent for v4) while :; do mount -t nfs4 &lt;server&gt;:/missing /mnt; done # watch SUnreclaim in /proc/meminfo grow 4 KiB per iteration</p> <p>Free the table on the error paths between the allocation and the assignment of se…</p> https://vulnerability.circl.lu/vuln/cve-2026-89714