Note: Versions mentioned in the description apply only to the upstream openshift/ose-rhel-coreos-9 package and not the openshift/ose-rhel-coreos-9 package as distributed by RHEL. See How to fix? for RHEL:9 relevant fixed versions and status.

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

NFS: fix delegation_hash_table leak when nfs4_server_common_setup() fails

nfs4_server_common_setup() allocates server->delegation_hash_table first, but server->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->destroy still NULL, so the caller's nfs_free_server() skips the destroy callback and the hash table is leaked (4 KiB per attempt with the default delegation watermark).

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).

Reproducer:

server exports NFSv3 only (or export path absent for v4)

while :; do mount -t nfs4 <server>:/missing /mnt; done

watch SUnreclaim in /proc/meminfo grow 4 KiB per iteration

Free the table on the error paths between the allocation and the assignment of server->destroy.

• https://access.redhat.com/security/cve/CVE-2026-89714
• https://git.kernel.org/stable/c/0fd2b9687dae36be5b84eab39b4c627bb7ab33b3
• https://git.kernel.org/stable/c/2092f5b38f88be306140c77aeeeb43fc1adacacc
• https://git.kernel.org/stable/c/f3adf1643517357221422c05986d6de5df7b9913