CVE-2024-47737

What it actually does

Missing cache_put call after successful cache_get in nfsd idmap_lookup when xdr_reserve_space returns NULL, causing unpaired reference count and potential memory corruption or resource leak in the Linux kernel NFS server.

Why it matters to the business

Local users on affected Linux systems can trigger denial of service against NFS services, leading to server instability and operational disruption in environments relying on kernel-based NFS exports; widespread kernel prevalence increases exposure across many deployments.

How an attack unfolds

A local attacker with low privileges crafts an NFS idmap request that exhausts buffer space in xdr_reserve_space after idmap_lookup has called cache_get; the missing cache_put leaves the cache entry referenced, enabling repeated operations that corrupt memory structures or exhaust resources.

How to fix it

Update the Linux kernel to commit 3e8081ebff12bec1347deaceb6bce0765cce54df or later; for Rocky Linux 8 libecap update to 0:1.0.1-2.module+el8.4.0+404+316a0dc5; rebuild and reboot with the patched kernel.

How to confirm the fix worked

Confirm kernel version contains commit 3e8081ebff12bec1347deaceb6bce0765cce54df via uname or package manager; test nfsd idmap paths under buffer pressure to verify cache_put pairing; monitor for absence of related memory leak reports post-upgrade.

Typical attack path

1. Obtain local user access on a system running vulnerable Linux kernel with nfsd enabled
2. Trigger NFS idmap operations that invoke lookup_fn and cache_get
3. Force xdr_reserve_space to return NULL due to insufficient buffer
4. Omit the paired cache_put, leaving dangling cache references
5. Repeat to induce memory corruption or resource exhaustion leading to denial of service

How to detect it

Review kernel logs for nfsd and idmap related warnings or oops messages around cache operations; inspect system call traces for repeated idmap_lookup under high load; correlate with local user activity on NFS-enabled hosts.

What your security team should do

• Prioritize patching Linux kernel on all systems exposing nfsd within 30 days given kernel prevalence
• Restrict local access to NFS servers to trusted users only
• Monitor kernel changelogs for backports of the fix into distribution kernels
• Audit nfsd configurations for unnecessary idmap usage